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Using  Spiral  Development  to 
Reduce  Acquisition  Cycle  Times 


by 

Jacques  S.  Gansler,  William  Lucyshyn,  and  Adam  Spiers 


Executive  Summary 

The  U.S.  military’s  mission  expanded  signifieantly  following  the  terrorist  attaeks  of 
9/1 1/01  and  with  the  subsequent  Global  War  on  Terror  (and  the  invasions  of  Afghanistan 
and  Iraq).  In  order  for  the  military  to  effeetively  respond  to,  and  eounter,  these  rapidly 
evolving  asymmetrie  and  irregular  threats,  the  military  needs  an  acquisition  system  that 
will  provide  the  required  weapons  quickly,  efficiently,  and  with  low  risk. 

Unfortunately,  rather  than  becoming  more  efficient,  the  DoD  has  faced  ever-lengthening 
development  cycles.  Long  developments  have  typically  been  justified  as  required  to 
fulfill  the  military’s  demand  for  cutting-edge  hardware.  Moreover,  long  development 
cycles  do  not  necessarily  provide  better  results.  A  technology  that  appears  to  have  a  high 
utility  at  initiation  may  only  prove  to  be  marginally  useful  once  the  technology  is  fully 
matured  and  deployed.  Additionally,  at  a  time  when  the  threat  is  rapidly  changing,  long 
development  cycles  may  produce  weapons  that  are  effective  for  a  problem  that  no  longer 
exists.  Importantly,  history  shows  that  the  longer  a  system’s  development  cycle,  the 
more  likely  a  program  is  to  experience  significant  cost  growth.  This  comes  at  a  time 
when,  we  believe,  the  nation’s  future  budgetary  situation — as  mandatory  federal  budget 
expenditures  rise — will  constrain  and,  more  likely,  exert  an  increasing  downward 
budgetary  pressure  on  future  defense  spending. 

The  DoD  has  historically  used  a  linear  acquisition  strategy  known  as  the  “waterfall” 
method.  The  waterfall  method  gave  military  planners  the  illusion  of  stability,  as  firm 
end-requirements  would  be  determined  early  in  the  development  process.  As  a  result. 
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key  development  decisions  would  be  made  before  sufficient  knowledge  was  available  to 
make  accurate  assessments. 

Recognizing  the  benefits  of  a  concept  developed  by  Barry  Boehm^  to  improve  the 
software  development  process — a  concept  he  called  “spiral  development” — a  growing 
number  of  senior  DoD  officials  came  to  believe  that  it  should  be  extended  to  the 
acquisition  of  the  DoD’s  software-intensive  weapons  systems  and,  subsequently,  to  all 
weapon  systems.  In  a  military  context,  spiral  development  is  understood  as  a  cyclical 
development  strategy,  wherein  a  basic  capability  is  fielded,  and  incremental  capability 
improvements  are  periodically  made  in  subsequent  blocks.  By  shortening  development 
timetables  and  ensuring  the  use  of  mature  technologies,  spiral  development  reduces  the 
risk  of  program  delay  or  failure. 

Although  the  spiral  development  process  appears  complex  at  first  glance,  a  simple  logic 
underlies  the  theory.  The  spiral  development  process  has  four,  well-defined  stages  that  a 
project  moves  through  during  the  progress  of  each  (and  every)  individual  spiral.  A  spiral 
development  project  may  undergo  any  number  of  spirals.  One  project  may  be  developed 
in  just  a  single  spiral,  spun-out  to  provide  an  urgently  needed,  interim  capability. 

Another  project  may  go  through  a  dozen  spirals  and  spin-outs  as  it  is  continually 
modified  and  updated.  The  flexibility  of  spiral  development  allows  planners  to  determine 
the  appropriateness  of  the  project  incrementally,  at  the  end  of  each  spiral.  The  DoD 
officially  endorsed  spiral  development  as  a  key  implementation  process  for  the  preferred 
evolutionary  acquisition  strategy  in  the  2003  version  of  DoD  Instruction  5000.2. 

One  of  spiral  development’s  primary  attributes  is  that  it  can  help  to  ensure  the  rapid 
deployment  of  weapon  systems.  Specifically,  when  systems  are  developed 
incrementally,  and  when  technology  is  mature  enough  to  be  integrated,  risk  is  minimized. 
As  a  result,  delays  in  development  are  reduced — keeping  cost  growth  in  check  as  well. 
Spiral  development  is  also  advantageous  because  of  its  ability  to  allow  for  evolving 
requirements.  Because  spirals  are  flexible  and  can  be  changed  as  the  program  progresses, 
spiral  development  permits  constant  refinement  over-time,  allowing  the  user  and 

*  See  Barry  Boehm’s  seminal  article  "A  Spiral  Model  of  Software  Development  and  Enhancement," 
Computer,  IEEE,  21(5):  61-72,  May  1988. 
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developer  to  hone  in  on  requirements  as  they  ehange.  Finally,  spiral  development  ean 
help  foster  a  robust  defense  industrial  base,  with  the  potential  for  eompetition  at  the 
beginning  of  each  spiral  (creating  broader  opportunity,  encouraging  innovation,  and  also 
leading  to  increased  pressures  on  private  industry  to  become  more  efficient  in 
production). 

We  believe  that  to  effectively  accomplish  the  required  modernization  of  the  military  to 
meet  the  challenges  of  the  twenty-first  century,  the  DoD  must  use  spiral  development  as 
an  acquisition  strategy.  Spiral  development  can  allow  the  DoD  to  field  weapons  faster, 
decrease  acquisition  costs,  promptly  adapt  to  changing  threat  requirements  and  foster  a 
more  competitive  defense  industrial  base. 

In  order  to  illustrate  the  challenges  and  benefits  of  using  spiral  development  in  the  DoD, 
this  report  examines  several  case  studies  that  demonstrate  implementation  of  spiral 
development  over  various  types  of  military  acquisitions.  We  first  examine  the  Predator 
Unmanned  Aerial  Vehicle  (UAV)  program,  as  it  is  one  of  the  most  successful  UAVs  ever 
built  and  an  exceptional  example  of  spiral  development  in  practice.  The  Predator 
demonstrates  the  adaptability  feature  of  the  spiral  development  process.  In  this  case,  the 
platform  itself  evolved  in  terms  of  capabilities  and  technical  performance,  just  as  the  user 
was  evolving  the  platform’s  application  during  combat. 

The  second  case  we  examine  is  the  Navy’s  Acoustic-Rapid  COTS  Insertion  (A-RCI) 
program.  The  A-RCI  program  displays  the  value  of  spiral  development  when  used  to 
upgrade  legacy  systems.  This  case  demonstrates  how  continuous  improvement,  through 
incremental  spirals,  allows  existing  platforms  to  be  upgraded  for  a  minimal  investment. 

The  third  case  we  examine  is  the  Global  Hawk  UAV  program.  This  program 
demonstrated  the  advantages  of  spiral  development  early-on,  but  began  to  have  cost  and 
schedule  issues  when  the  Air  Force  continued  to  add  new  requirements  and  did  not  keep 
the  cost  targets  (as  “requirements”).  These  new  performance  requirements  (without  cost 
controls)  resulted  in  a  significantly  larger  air  vehicle,  and  significant  program  cost 
growth. 
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Next,  we  examine  the  Navy’s  Littoral  Combat  Ship  (LCS)  ease  as  an  example  of  spiral 
development  program  that  was  not  properly  exeeuted;  it  was  not  a  well-diseiplined 
program.  An  aggressive  sehedule  and  unrealistie  eost  estimates  led  to  numerous  delays 
and  eost-inereases.  Unrealistie  assumptions,  eoupled  with  little  flexibility  in  the  Navy’s 
requirements,  ultimately  diminished  the  effeetiveness  of  the  spiral  approaeh  in  this  ease. 

Finally,  we  inelude  a  review  of  the  eommereial  development  of  INTELSAT.  Although  it 
was  not  a  spiral  development  in  the  formal  sense,  the  program  suoeessfully  developed 
satellites  quiekly  and  effieiently,  using  mature  teehnologies  and  periodie  updates. 

In  order  to  implement  spiral  development  DoD-wide,  it  is  neeessary  for  deeision-makers 
to  aeeount  for  several  ehallenges  that  eould  impede  the  expanded  use  of  spiral 
development  praetiees.  First,  DoD's  aequisition  eulture  is  resistant  to  ehange,  as  it  is 
eurrently  founded  on  deeades  of  edueation  and  training  rooted  in  Cold- War-based 
aequisition  philosophies.  Seeond,  eurrent  funding  proeesses,  both  within  the  DoD  and  the 
federal  government  itself,  are  not  struetured  to  support  the  flexibility  and  ehange  of  spiral 
development.  Third,  the  regulatory  environment  is  not  designed  to  address  an  aequisition 
strategy  that  requires  flexibility  and  quiek  development/aetion.  Fourth,  eontinuously 
ehanging  requirements,  without  adequate  eost/performanee  trade-offs  (eommonly  known 
as  the  "requirements  ereep")  is  still  a  major  faetor  in  eurrent  programs  and  leads  to  eost 
inereases  and  sehedule  delays.  Fifth,  many  eurrent  programs  are  initiated  without 
deeision-makers  having  the  knowledge  of  risk  neeessary  to  suoeessfully  oomplete  the 
tasks  they  have  already  oommitted  to  doing.  Sixth,  oommunioation  between  all 
stakeholders  is  vital  for  spiral  development  to  be  effeotive;  and,  at  present,  this  level  of 
oommunioation  is  not  oommon  in  many  system  development  programs.  Finally, 
supportability  of  programs  is  key;  if  shareholders  do  not  oommunioate  with  the  logistios 
oommunity  as  oapabilities  and  requirements  ehange,  logistios  support  beoomes  extremely 
oomplex  and  diffioult  to  manage. 

In  light  of  these  ehallenges,  the  authors  of  this  report  make  the  following  speoifio 
reo  ommendations : 
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1.  Use  Mature  Technologies  and  Knowledge-based  Practices.  The  wider  use  of 
mature  teehnology  (for  each  spiral)  and  knowledge-based  practices  is  vital,  as  it  has  been 
proven  to  directly  reduce  cost  and  schedule  risk. 

2.  Program  Must  Have  Greater  Requirements  Flexibility.  Increased  flexibility  in 
program  requirements  is  key  as  technology  is  developed  incrementally;  spiral 
development  is  designed  to  use  cost,  schedule  and  performance  trade-offs,  over-time,  to 
ensure  ultimate  program  success. 

3.  Address  the  Budget  Challenges.  Current  budget  challenges  must  be  overcome,  and 
wider  acceptance  of  the  spiral  approach,  through  funding  procedures,  must  be  recognized. 

4.  Adapt  Test  and  Evaluation  Processes.  The  testing  and  evaluation  process  is  not 
designed  to  accommodate  spiral  development;  these  procedures  must  be  redesigned  to 
account  for  a  spiral  approach  to  acquisition. 

5.  Incorporate  Logistical  Concerns  Early  in  the  Development  Process.  Fifth, 
logistics  must  be  accounted  for  and  incorporated  early  in  the  development  process  and 
must  include  communication  with  all  key  stakeholders. 

6.  Ensure  that  Programs  are  Properly  Managed.  Programs  must  be  properly 
managed  under  spiral  development;  an  important  factor  in  their  success  is  the  progression 
from  one  block  to  the  next,  and  this  requires  sufficient  oversight  and  management. 

7.  Implement  Modular-Open-System  Approach.  Further  use  of  a  modular-open- 
system  approach  will  allow  greater  opportunity  for  the  inclusion  of  the  lowest-cost  and 
best-performing  components  in  a  system  sooner  rather  than  later. 

8.  Ensure  Programs  use  Concurrent  development.  Spiral  development  relies  upon 
the  concurrent  development  of  sequential  spirals;  i.e.,  spiral  N  and  spiral  N+l  will 
partially  overlap.  Consequently,  planning  for  spiral  “N+l”  is  a  critical  spiral  “N”  task. 

It  is  our  belief  that  if  these  steps  are  taken,  spiral  development  can  be  properly 
implemented  and  expanded  DoD-wide.  In  order  to  accomplish  this,  however.  Department 
leadership  must  overcome  numerous  challenges.  We  believe  that  current  cases  exemplify 


the  benefits  that  ean  be  had  from  spiral  development  and  hold  a  promise  of  even  greater 
achievements  in  future  programs.  To  achieve  the  required  DoD  modernization  for  the 
twenty-first  century,  developers  must  begin  to  field  better-performing,  lower-cost 
systems,  faster;  we  believe  spiral  development  to  be  at  the  core  of  that  effort. 


I.  Introduction 


The  United  States  eurrently  faees  an  uncertain  and  rapidly  changing  threat  environment. 
This  situation  is  in  stark  contrast  to  America’s  experience  during  the  Cold  War,  with  the 
singular  and  generally  predictable  threat  posed  by  the  Soviet  Union.  Following  the 
collapse  of  the  Soviet  Union,  the  United  States  military  began  to  undertake  a  variety  of 
less  traditional  missions,  such  as  nation-building  and  peacekeeping — missions  outside  the 
realm  of  its  more  traditional  areas  of  expertise.  The  military’s  operational  mission 
expanded  significantly  following  the  terrorist  attacks  of  9/1 1/01  and  with  the  subsequent 
Global  War  on  Terror  and  the  invasions  of  Afghanistan  and  Iraq.  In  order  for  the  military 
to  effectively  respond  to,  and  counter,  these  rapidly  evolving,  asymmetric  and  irregular 
threats,  the  military  needs  an  acquisition  system  that  will  provide  the  required  weapons 
quickly  and  efficiently. 

Military  planning  during  the  Cold  War  was  relatively  stable,  predictable  and  consistent. 
The  DoD  employed  a  threat-based  planning  approach  to  prepare  for  possible  conflict  with 
the  Soviet  Union  and  its  allies.  Intelligence  could  provide  reasonably  accurate  estimates 
regarding  enemy  capabilities,  numbers,  and  disposition.  The  goal  for  the  DoD’s 
acquisition  community  was  to  stay  technologically  ahead  of  the  enemy.  Developers 
could  reasonably  assume  that  future  needs — tanks,  planes,  and  ships — ^would  not  differ 
from  the  past  substantially  in  mission  requirements,  merely  in  quality.  The  United  States 
could  prepare  for  a  threat  it  understood  (or  at  least  believed  it  understood)  well. 

Circumstances  changed  following  the  fall  of  the  Soviet  Union.  The  absence  of  a  clear 
and  present  threat  led  to  a  period  of  military  retrenchment,  as  the  nation  demanded  to 
reap  the  benefits  of  the  “peace  dividend.”  Issues  submerged  during  the  Cold  War 
suddenly  became  important  enough  to  warrant  military  action;  consequently,  the 
military’s  role  expanded  during  the  post-Cold  War  era.  New  missions  included  providing 
humanitarian  assistance,  disaster  relief,  drug  interdiction,  border  patrol,  and  nation¬ 
building.  In  an  effort  to  respond  to  these  new  missions,  the  military  used  the  available 
forces,  weapons,  and  doctrine — with  varying  degrees  of  success. 
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September  1 1**',  2001,  brought  to  light  one  of  a  range  of  unforeseen  threats  that  direetly 
threatened  the  United  States  homeland.  Suddenly,  terrorists,  rogue  states,  failed  states, 
and  other  non-state  actors  became  prominent  national  security  concerns.  The  scope  of 
the  military’s  action  would  increase  significantly  following  the  terrorist  attacks  of  9/1 1 
and  the  subsequent  military  interventions  in  Afghanistan  and  Iraq. 

With  the  development  of  these  new,  more  complex  threats,  the  United  States  needs  a 
defense  acquisition  system  flexible  enough  to  effectively  and  efficiently  respond  in  a 
timely  manner.  There  are  several  factors  (that  include  severe  budget  constraints, 
lengthening  acquisition  cycles,  and  the  legacy  “waterfall”  acquisition  method)  that  help 
to  define  the  DoD’s  current  acquisition  environment;  these  are  discussed  below. 

Budget  Constraints 

The  nation’s  overall  future  budgetary  situation  will  constrain  future  DoD  funding.  As 
mandatory  federal  budget  expenditures  rise — particularly  for  Social  Security,  Medicare 
and  Medicaid — there  will  be  increasing  downward  budgetary  pressure  on  defense 
spending.  Moreover,  the  acquisition  budget  may  fall  at  an  increased  rate,  as  the 
Congressional  Budget  Office  projects  a  relative  decline  in  the  percentage  of  the  DoD 
budget  spent  on  acquisition.  As  a  result,  the  acquisition  budget  will  face  reductions  for 
two  reasons:  (1)  the  overall  decline  in  the  military  budget  and  (2)  the  relative  decline  of 
the  acquisition  budget  as  a  portion  of  military  spending. 

The  military  budget,  as  a  percentage  of  GDP,  has  steadily  declined  since  the  end  of  the 
Korean  War.  This  decline  was  accelerated  by  the  substantial  military  budget  cuts 
following  the  end  of  the  Cold  War  that  were  enacted  to  recoup  the  perceived  peace 
dividend.  Military  spending  fell,  as  a  percentage  of  GDP,  from  an  average  of  5.75%  in 
the  1980s  to  3.96%  in  the  1990s  (Table  3.1)  (Office  of  Management  and  Budget  2004). 
Although  military  spending  has  increased  since  2001  due  to  increased  military 
operations,  the  Congressional  Budget  Office  projects  a  further  decline  in  the  percentage 
of  GDP  allocated  to  defense  in  the  near  future  (see  Figure  1). 
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Past  and  Projected  Spending  for  National  Defense 


(Billions  of  2008  Dollars  of  Outlays  and  Outlays  as  a  Percentage  of  Gross  Domestic  Product) 


Figure  1:  Past  and  Projected  Spending  for  National  Defense  (CBO  2008) 

The  growth  in  mandatory  expenditures  will  further  eonstrain  future  U.S.  military 
expenditures.  Entitlement  programs  such  as  Social  Security  and  Medicare  project 
massive  deficits  starting  early  in  the  2010s  and  growing  worse  as  the  Baby  Boomers 
retire  in  increasing  numbers.  By  2017,  the  annual  growth  rate  of  Social  Security 
spending  is  expected  to  rise  from  4.5%  to  6.5%,  while  Medicare  and  Medicaid  are 
projected  to  grow  in  the  range  of  7%  to  8%  annually.  Servicing  the  large  and  expanding 
public  debt,  already  9%  of  federal  spending  in  2006  (Walker  2007)  will  restrict  funds 
available  for  discretionary  expenditures. 

Acquisition  (RDT&E  and  Procurement)  will  be  most  adversely  affected  by  the  DoD’s 
budget  decline.  As  shown  in  Eigure  2,  this  portion  of  the  budget  is  projected  to  shrink 
over  the  next  15  years.  Operations  &  Maintenance  (O&M)  funding  currently  represents 
nearly  two-thirds  of  the  DoD  budget,  while  resources  devoted  to  modernization  represent 
only  one  third.  The  Congressional  Budget  Office  forecasts  significant  increases  in 
spending  on  personnel  and  O&M,  which  are  projected  to  rise  30%  and  20%  respectively 
by  2024.  During  this  same  period,  funds  invested  in  RDT&E  are  expected  to  decline  by 
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roughly  one-third — which  will  negatively  impact  innovation  and  modernization  within 
the  military  (Congressional  Budget  Office  2006).  CBO  projections  may  underestimate 
RDT&E  cutbacks  due  to  factors  ranging  from  the  length  of  military  presence  in  Iraq  and 
Afghanistan  to  the  rapidly  growing  costs  of  healthcare  for  the  care  of  soldiers,  civilian 
personnel,  and  their  families.  Ultimately,  the  declining  military  budget  will  force  the 
nation  to  make  many  hard  decisions  as  “the  Department  of  Defense  must  cope  with 
conflicting  imperatives — adapting  to  a  rapidly-changing  security  environment,  while 
preserving  the  capability  to  field  a  military  unparalleled  in  history”  (21)  (CSIS  2004). 


Past  and  Projected  Funding  for  Defense 


1980  1965  1990  1995  2000  2005  2010  2015  2020  2025 


Figure  2:  Past  and  Projected  Funding  for  Defense  (Billions  of  2008  Dollars  of  Total  Obligation 
Authority)  (CBO  2008) 
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Delayed  Schedules 


As  technology  has  become  increasingly  complex  over  the  past  decades,  the  DoD  has 
faced  ever-lengthening  development  cycles.  Long  development  cycles  have  typically 
been  justified  as  required  to  fulfill  the  military’s  demand  for  cutting-edge  hardware. 
Historically,  though,  the  longer  a  development  cycle,  the  more  likely  a  program  is  to 
experience  significant  cost  growth.  As  the  time  horizon  extends,  it  becomes  more 
difficult  to  properly  estimate  the  risks  associated  with  development. 

A  recent  Government  Accountability  Office  (GAO)  report  highlights  the  problem  of  the 
lengthy  development  cycles  that  DoD  acquisitions  currently  experience.  The  weighted- 
average  acquisition  cycle  time  estimate  of  27  major  weapons  acquisition  platforms  was 
170.2  months — a  little  over  14  years  (see  Figure  3).  On  average,  these  programs 
experienced  growth  cost  of  19.1%,  RDT&E  cost  growth  of  33.5%  and  acquisition  cycle 
growth  of  23.5%.  Certain  projects,  such  as  the  Air  Force’s  F-22  and  Joint  Strike  Fighter, 
experienced  even  greater  growth  in  cost  and  cycle  times.  Program  cost  growth,  primarily 
occurring  in  RDT&E,  would  have  grown  even  more  if  the  military  did  not  reduce 
requirements  capabilities  and  procurement  numbers.  Despite  these  increases,  the  GAO 
warns  that  future  development  delays  and  rising  costs  are  likely,  as  many  technologies  for 
these  programs  have  yet  to  reach  maturity. 


First  full  estimate 

Latest  estimate 

Percent  change 

Total  Cost 

$506.4 

$603.1 

19.1% 

RDT&E  Cost 

$104.7 

$139.7 

33.5% 

Weighted  average 
acquisition  cycle 
time  in  months 

137.9 

170.2 

23.5% 

Figure  3:  Cost  and  Cycle  Time  Growth  for  27  Weapons  Systems  (Billions  of  Constant  2007  dollars) 
(GAO  07-406SP) 
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In  contrast  to  the  difficulties  faeed  by  DoD  aequisition  projects,  private  industry  has  been 
able  to  signifieantly  reduce  development  cyeles.  From  1969  to  1998,  the  average  eyele 
time  of  an  average  DoD  development  program  increased  from  approximately  80  months 
to  107  months.  In  eontrast,  the  private  automobile  industry  experieneed  signifieant 
reductions  in  average  cycle  times,  from  approximately  90  months  to  24  months  (Figure  4 
below).  Much  of  the  decrease  in  cycle  times  took  place  during  the  1990s,  when  the 
private  automotive,  aircraft,  spacecraft  and  electronics  industries  deereased  cycle  time  by 
an  average  of  50-75%  (Ward  2006). 


Long  development  times  increase  the  chance  of  technology  obsolescence  and  cost  growth 


Source:  DSB  Briefing,  Dan  Czelusniak,  12  June  1998 


Figure  4.  Average  DoD  Program  Cycle  Times  (by  SAR  Reporting  Years) 


Long  acquisition  cycles  have  other  undesirable  effects  on  development  projects.  Long 
and  fixed  development  cycles  have  not  enabled  DoD  aequisition  projects  to  include  new 
technologies  as  they  become  available  on  the  market.  Today,  most  technical  innovation 
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occurs  outside  of  the  government;  eonsequently,  the  DoD  loses  many  relevant 
opportunities.  Moreover,  with  the  increasing  speed  of  teehnical  innovation,  systems 
beeome  obsolete  at  a  faster  rate.  As  a  result,  many  programs  or  eomponents  of  systems 
involving  a  lengthy  development  cyele  beeome  obsolete  even  before  the  deployment  of 
the  system. 

Furthermore,  long  development  cycles  do  not  necessarily  provide  more  reliable  results. 
A  technology  that  appears  to  have  a  high  utility  at  program  initiation  may  only  prove  to 
be  marginally  useful  once  the  technology  is  fully  matured  and  deployed.  Long 
development  cycles  may  also  produee  weapons  that  are  designed  for  a  problem  that  no 
longer  exists. 


Time  to  First  Operational  Delivery 


Figure  5.  Average  Cost  Growth  for  DoD  Programs  (McNutt  PhD  Dissertation  1998) 

The  final  issue  is  the  impact  of  long  development  cycles  on  cost  growth.  The  longer  a 
military  program  is  in  development,  the  higher  the  average  eost  growth  factor.  The 
average  cost  growth  factor  indicates  how  mueh  the  cost  of  a  program  increases  over  the 
program’s  original  estimate,  given  as  a  percentage  of  the  original  estimate.  The  shorter 
time  period  a  military  program  is  in  development,  the  lower  the  average  eost  growth 
factor.  A  RAND  analysis  of  Selected  Acquisition  Reports  in  1996  found  that  programs 
taking  less  than  7  years  to  reach  first  operational  delivery  overran  their  initial  planned 
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development  budgets  by  an  average  of  15%,  while  programs  taking  longer  than  14  years 
overran  their  initial  planned  development  budgets  by  an  average  of  42%.  Clearly, 
development  cycles  should  be  kept  as  short  as  possible  to  minimize  the  risk  of  cost 
growth  (see  Figure  5). 

Waterfall  Method 

The  Department  of  Defense  has  historically  used  a  linear  acquisition  strategy  known  as 
the  “waterfall”  method.  The  waterfall  method  gave  military  planners  the  illusion  of 
stability,  as  firm  end  requirements  would  be  determined  early  in  the  development 
process.  Key  development  decisions,  however,  would  be  made  before  sufficient 
knowledge  was  garnered  to  make  an  accurate  assessment  of  feasibility.  A  program 
would  only  be  considered  complete  when  the  final  requirements  were  met,  regardless  of 
changes  that  may  occur  during  development.  The  need  to  maintain  technical  superiority 
over  adversaries  pushed  the  military  to  design  systems  that  would  provide  revolutionary 
steps  in  warfighting.  These  leaps  in  capability  were  predicated  on  the  successful  and 
flawless  development  of  immature  technologies.  The  need  for  serial  “big-bang” 
innovations  drove  long  cycle  times.  As  a  result  of  this  risky  development  strategy,  tight 
schedules  would  often  slip  as  immature  technology  could  not  meet  design  specifications. 
As  the  development  timetable  lengthened,  and  the  DoD  paid  for  expensive  engineers  to 
remain  on  the  project,  the  cost  of  programs  rapidly  escalated. 

At  one  point,  all  private  firms  utilized  the  waterfall  technique  of  development.  Over  time, 
however,  firms  began  to  adopt  new  cyclical  acquisition  techniques  to  survive,  as 
competition  became  fiercer.  Firms  developed  new  acquisition  methods  because  they 
discovered  that  long  development  periods  cause  cost  growth.  The  longer  a  project  is  in 
development,  the  more  time  likely  something  will  “go  wrong”:  budget  instability, 
schedule  changes,  cost  increases,  new  technology,  requirements  “creep,”  etc.  Problems 
associated  with  linear  acquisition  projects  included  the  inability  to  incorporate  newly 
matured  technologies  into  designs,  the  inflexibility  to  change  end  requirements  to 
respond  to  emerging  threats,  and  difficulty  in  incorporating  user  feedback  into  future 
modifications.  All  too  often,  a  military  project  would  set  itself  up  for  failure  by 
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establishing  a  baseline  development  timetable  that  exeeeded  a  deeade.  Overall,  the 
waterfall  method  was  too  rigid  to  adapt  to  ehanges  that  might,  and  more  often  than  not 
did,  oeeur  during  development. 

Report  Roadmap 

Seetion  One  of  this  report  has  provided  an  overview  of  the  eontributing  environmental 
faetors  impaeting  the  present  state  of  DoD  aequisition.  Seetion  Two  will  provide  a  brief 
history  of  spiral  development  itself,  explain  in  detail  the  proeess,  and  outline  the 
evolution  of  government  poliey.  Seetion  Three  will  examine  five  eases  of  spiral 
development:  the  Predator  UAV  program,  the  Aeoustie  Rapid  COTS  Insertion  (A-RCI) 
program,  the  Global  Hawk  UAV  program,  the  Littoral  Combat  Ship  (LCS)  program,  and 
eommereial  development  of  INTELSAT.  Each  of  these  cases  will  provide  background 
information  on  the  circumstances  surrounding  the  case,  an  overview  of  the  program  itself 
and  important  developments,  along  with  results  of  each  and  any  lessons  learned.  Section 
Eour  will  provide  overall  findings  regarding  the  implementation  of  spiral  development  in 
DoD  acquisitions  thus  far  and  our  recommendations  for  the  increased  and  improved  use 
of  spiral  development.  Section  Eive  will  provide  our  final  conclusions. 
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II.  Spiral  Development 


History 

Throughout  the  1970s  and  1980s,  firms  pursuing  software  development  experieneed 
many  of  the  same  ehallenges  that  the  DoD  faced  in  its  military  acquisition.  During  this 
time  period,  software  development  became  an  increasingly  intricate  and  complicated 
undertaking.  Even  with  teams  of  programmers  with  specialized  knowledge,  large-scale 
projects  often  experienced  debilitating  delays  and  cost  overruns.  The  DoD  and  the 
software  industry  employed  the  same  linear  acquisition  strategy  and  experienced  equally 
disappointing  results. 

In  1988,  Barry  Boehm  first  put  forth  the  Spiral  Development  theory  in  his  article  A  Spiral 
Model  of  Software  Development  and  Enhancement.  The  paper  explicitly  provided  a 
software  development  strategy  that  increased  efficiency  markedly  over  its  predecessor. 

As  described  by  Boehm,  the  Spiral  Development  model  “creates  a  risk-driven  approach 
to  the  software  process  rather  than  a  primarily  document-driven  or  code-driven  process.” 
(emphasis  in  original)  (Boehm  1988).  The  process  emphasizes  effective  risk 
management  as  the  key  to  effective  development,  not  strict  adherence  to  a  predetermined 
(and  often  arbitrary)  schedule.  Boehm  based  the  paper  on  his  personal  experience 
utilizing  this  development  strategy  while  designing  large  government  software  programs 
for  TRW  Defense  Systems  Group  during  the  1980s.  Boehm  would  go  on  to  refine  his 
model  and  its  assumptions  in  later  works. 

Boehm  surmised  that  the  sequential  development  process  tended  to  perform  poorly 
because  it  was  inflexible.  By  committing  early  to  a  final  developmental  approach,  before 
the  acquisition  team  had  sufficient  knowledge,  a  firm  would  make  decisions  without  an 
effective  understanding  of  the  associated  risks.  All  too  often,  due  to  the  lack  of 
knowledge,  senior  management  would  set  desired,  yet  unrealistic  end-goals.  By  being 
committed  to  fixed  long-term  objectives  early  in  the  development  process,  most  projects 
precluded  the  incorporation  of  important  innovations  that  arose  during  development.  To 
overcome  the  challenges  faced  by  the  linear  development  model,  Boehm  proposed  the 
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spiral  development  process:  a  “risk-driven,  process-model  generator  [...with]  two 
distinguishing  features.  One  is  a  cyclical  approach  for  incrementally  growing  a  system's 
degree  of  definition  and  implementation,  while  decreasing  its  degree  of  risk.  The  other  is 
a  set  of  anchor  point  milestones  for  ensuring  stakeholder  commitment  to  feasible  and 
mutually-satisfactory  system  solutions"(3)(Boehm  2000). 

Boehm  also  summarized  the  most  important  features  of  the  spiral  development  model  as 
“cyclic  concurrent  engineering;  risk-driven  determination  of  process  and  product; 
growing  a  system  via  risk-driven  experimentation  and  elaboration;  and  lowering 
development  cost  by  early  elimination  of  nonviable  alternatives  and  rework 
avoidance”(3)(Boehm  2000).  All  of  these  aspects  characterize  a  process  that  emphasizes 
knowledge-based  development,  founded  upon  effective  risk  management.  Due  to  this 
prominence,  spiral  development  has  two  primary  advantages  over  the  traditional 
acquisition  method:  its  cyclical  approach  allows  users  to  provide  feedback  at  every 
development  step,  and  developers  can  identify  potential  trouble  spots  at  an  early  stage. 

Spiral  Development:  The  Process 

Although  the  Spiral  Development  process  appears  complex  at  first  glance,  a  simple  logic 
underlies  the  theory.  The  spiral  development  process  has  four,  well-defined  stages  that  a 
project  moves  through  during  the  progress  of  each  (and  every)  individual  spiral.  A  visual 
depiction  of  a  theoretical  spiral  development  process  is  presented  below,  in  Figure  6.  (In 
a  realistic  scenario,  however,  each  phase  is  unlikely  to  constitute  an  equal  investment  of 
time.) 
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Figure  6.  Spiral  Development  Model.  (Source  for  Image: 
http://www.stsc.hill.af  mil/crossTalk/2001/05/boehml. gif) 

The  first  stage  is  the  determination  phase.  In  this  segment,  project  managers  decide  on 
the  objectives,  alternatives  and  constraints  of  the  project  for  the  entire  spiral.  The  goal  of 
this  stage  is  to  determine  all  feasible  avenues  of  development  that  the  project  could 
pursue  in  the  current  spiral.  By  the  end  of  the  phase,  the  engineering  team  develops 
several  design  options  to  explore. 

During  the  second  stage,  all  alternatives  from  the  first  stage  are  assessed  with  regard  to 
their  risks.  After  the  risk  analyses  are  complete,  the  project  team  comes  to  a  decision  on 
the  best  course  of  action  for  the  spiral.  By  the  end  of  this  phase,  the  design  team 
produces  prototypes  to  test  the  validity  of  the  initial  analysis. 

The  third  step  of  spiral  development  is  the  longest.  In  this  phase,  the  time-intensive 
process  of  development  and  verification  of  the  product  occurs.  Development  continues 
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until  the  final  product  of  that  spiral  is  produced  and  tested.  Validation  of  the  product  is 
also  undertaken  to  assure  quality  control. 

In  the  final  phase,  program  mangers  plan  for  future  spirals.  All  the  project’s  participants 
conduct  an  assessment  in  light  of  the  most  recent  spiral.  This  phase  ultimately 
culminates  in  a  milestone  checkpoint,  during  which  project  leaders  determine  the  future 
course  of  the  program.  At  this  point,  a  project  may  either  be  ended,  further  developed,  or 
“spun-out”  into  production.  If  more  progress  is  deemed  necessary,  the  requirements  for 
future  spirals  will  be  extensively  planned.  A  new  spiral  may  not  commence  until  a 
thorough  plan  detailing  the  goal  and  requirements  of  that  spiral  are  completed.  Once  a 
plan  of  action  is  agreed  to  and  approved  from  above,  the  spiral  process  once  again  begins 
at  the  first  phase  determination. 

A  spiral  development  project  may  undergo  any  number  of  spirals.  One  project  may  be 
developed  in  just  a  single  spiral,  spun-out  to  provide  an  urgently  needed  interim 
capability.  Another  project  may  go  through  a  dozen  spirals  and  spin-outs  as  it  is 
continually  modified  and  updated.  The  flexibility  of  spiral  development  allows  planners 
to  determine  the  appropriateness  of  the  project  incrementally  at  the  end  of  each  spiral. 

Recognizing  the  benefits  of  the  spiral  development  concept,  a  growing  cadre  of  senior 
DoD  officials  came  to  believe  that  the  process  could,  and  should  be,  extended  to  the 
acquisition  of  the  new  class  of  software-intensive  weapons  systems.  In  a  military 
context,  spiral  development  is  understood  as  a  cyclical  development  strategy — wherein  a 
basic  capability  is  fielded,  and  incremental  capability  improvements  are  periodically 
made  in  subsequent  blocks.  By  shortening  development  timetables  and  ensuring  the  use 
of  mature  technologies,  spiral  development  reduces  the  risk  of  program  delay  or  failure. 
The  speedy  deployment  of  a  major  weapons  system  (in  3-5  years)  allows  the  military  to 
more  rapidly  respond  to  an  emerging  threat.  The  weapons  developed  in  the  first 
increment  may  provide  a  weapon  only  somewhat  better  than  what  is  already  fielded. 
Continuous  upgrades,  however,  allow  for  improvement  in  capability  to  eventually  attain  a 
“revolutionary”  edge  over  opponents.  Although  a  system  will  be  less  than  full  capability 
(and  less  than  fully  tested)  when  first  deployed,  the  project  is  more  likely  to  remain 
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within  cost,  more  likely  to  be  delivered  earlier  than  a  comparable,  traditional  aequisition 
project,  and  more  likely  to  remain  more  adaptable  to  future  threats — all  while  the  risk  of 
failure  is  redueed. 

Policy 

The  DoD  recognized  that  a  knowledge-based  aequisition  strategy  is  essential  to 
effeetively  managing  risk.  A  knowledge-based  aequisition  strategy  is  one  whieh  relies 
solely  upon  the  use  of  mature  teehnologies  so  as  to  minimize  the  risk  of  eostly 
development  delays.  As  eoneluded  by  many  government  and  independent  reports, 
“immature  technologies  are  markers  for  future  eost  growth”  (GAO  2007).  Consequently, 
the  DoD  embraeed  Evolutionary  Aequisition  (EA),  a  strategy  based  on  the  use  of  mature 
teehnologies.  The  belief  was  that  evolutionary  aequisition  would  allow  for  faster 
implementation  of  improvements  as  new  teehnologies  beeame  available,  would  better 
balanee  needs  and  eapabilities  with  resourees,  and  would  take  advantage  of  user  feedback 
in  refining  requirements  and  eapabilities. 

The  DoD  offieially  endorsed  evolutionary  aequisition  as  the  preferred  strategy  for 
weapon  system  aequisition  in  the  DoD  Instruction  5000.1  series  issued  on  Oetober  23, 
2000.  Evolutionary  Aequisition  is  based  upon  five  key  tenets:  rapid  deployment; 
ineremental  development  of  eapabilities;  constant  refinements  and  adaptability  of 
requirements;  intensive  eollaboration  between  the  user,  tester,  developer  and  supporter; 
and  development  using  mature  teehnologies.  Teehnology  maturity  was  evaluated  using 
Teehnology  Readiness  Eevels  (see  Eigure  7).  In  that  year’s  version  of  the  DoD 
Instruction  5000.2  series,  spiral  development  was  also  identified  as  the  preferred  strategy 
for  software  development  programs. 


Evolutionary  Acquisition  is  the  DoD’s  preferred  broad  strategy  to 
satisfy  operational  needs;  while  Spiral  Development  is  the  preferred 
process  for  executing  such  a  strategy. 

DoDI  5000.2,  May  12,  2003 
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Technology  Readiness  Levels 


System  Test,  Launch  & 
Operations 


Syste  m/Su  bsyste  m 
DeveloRoiBiit _ 


Technology 

Demonstration 


Technology 

Developmen^^_ 

Research  to  Prove 
Feasibility 


Basic  Technology 
Research _ 


TRL9 

TRL8 

TRL7 

TRL6 


TRL5 

TRL4 

TRL3 


Actual  system  “flight  proven”  through 
successful  mission  operations 

Actual  system  completed  and  “flight 
qualified”  through  test  and  demonstration 

System  prototype  demonstration  in  a 
operational  environment 

System/subsystem  model  or  prototype 
demonstration  in  a  relevant  environment 

Component  and/or  breadboard  validation 
in  relevant  environment 

Component  and/or  breadboard  validation 
in  laboratory  environment 

Analytical  and  experimental  critical 
function  and/or  characteristic  proof-of- 
concept 

Technology  concept  and/or  application 
formulated 

Basic  principles  observed  and  reported 


Facing  technical  difficulties  in  the  late  1980s,  NASA  internally  developed  a  system  to  evaluate  technology 
maturity,  known  as  Technical  Readiness  Levels  (TRLs).  The  TRL  system  codifies  a  common  standard 
against  which  technologies  can  be  evaluated.  DoD  would  officially  endorse  the  system  in  2001 .  The  above 
summarizes  the  various  technology  readiness  levels  and  descriptions  as  defined  in  DoD  5000. 2-R,  April 
5,  2002. 


Figure  7.  Technology  Readiness  Levels 

The  initial  implementation  of  evolutionary  aequisition  and  spiral  development  was 
hindered  in  part  by  the  DoD’s  ambiguous  definition  of  the  relevant  terms  and  how  they 
should  be  implemented.  The  issue  was  speeifieally  addressed  in  the  revised  version  of 
the  Instruction  5000.2  series  in  2003.  With  this  publieation,  the  Department  reeognized 
that  the  evolutionary  acquisition  strategy  has  two  implementation  processes:  Incremental 
Development  and  Spiral  Development.  In  both  cases,  desired  end-capabilities  are 
clearly  defined.  A  capability  is  the  desired  function  that  the  deployed  weapon  system 
will  achieve.  With  incremental  development,  the  system’s  final  requirements  are  known. 
With  Spiral  Development,  although  the  desired  capability  is  identified,  specific  end-state 
requirements  are  not  known  quantitatively  at  the  program’s  initiation.  Furthermore, 
requirements  for  future  increments  may  change  depending  upon  technology  maturation 
and  user  feedback  from  initial  increments. 

2 

Capability  is  the  ability  to  achieve  a  desired  effect  under  specified  standards  and  conditions  through 
combinations  of  ways  and  means  to  perform  a  set  of  tasks.  It  is  defined  by  an  operational  user  and 
expressed  in  broad  operational  terms  (CJCSI  3 170. OIF  1  May  2007). 
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Upon  official  endorsement  of  evolutionary  aequisition  and  spiral  development,  many 
DoD  projeets  “diseovered”  that  they  had,  in  faet,  been  following  an  evolutionary 
aequisition/spiral  development  path  all  along,  as  program  managers  rushed  to  reelassify 
their  programs.  Although  labels  ehanged,  underlying  aequisition  praetiees  did  not 
ehange.  Consequently,  aequisition  problems  eontinued. 

Congress  also  amended  Title  10  to  explieitly  define  spiral  development  to  preelude 
arbitrary  program  redefinition  or  the  introduetion  of  “produet  improvements”  that  were 
really  brand-new  development  efforts  or  programs.  The  new  law  stipulates: 


U.S.  Code  Title  10,  Subtitle  A,  Part  IV,  Chapter  144,  Sec  144 

(g)  Definitions. — In  this  section: 

(1)  The  term  'spiral  development  program',  with  respect  to  a  research  and  development 
program,  means  a  program  that — 

(A)  is  conducted  in  discrete  phases  or  blocks,  each  of  which  will  result  in  the  development 
of  fieldable  prototypes;  and 

(B)  will  not  proceed  into  acquisition  until  specific  performance  parameters,  including 
measurable  exit  criteria,  have  been  met. 

(2)  The  term  'spiral'  means  one  of  the  discrete  phases  or  blocks  of  a  spiral  development 
program. 

(3)  The  term  'major  defense  acquisition  program '  has  the  meaning  given  such  term  in  section 
139(a)(2)(B)  of  title  10,  United  States  Code. 

Figure  8  provides  a  visual  representation  of  a  how  a  DoD  spiral  development  program 
should  be  developed  within  the  DoD’s  eurrent  aequisition  proeess,  emphasizing  the 
eoneurrent  nature  of  spiral  development.  The  Milestones  ean  be  viewed  as  eorresponding 
to  deeision  points  at  eaeh  axis  in  the  spiral  development  model  above. 
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Spiral  Development 


Spiral  I 


Experimentation 


Spiral  III 


New,  Proven** 
Technology 


Proven  =  TRL  6,  MRL  6 


Figure  8.  Spiral  Development  Program 

Advantages  of  Spiral  Development 

With  Spiral  Development,  the  DoD  believes  it  will  field  weapons  systems  faster,  reduce 
acquisition  costs,  and  be  able  to  more  easily  adapt  to  changing  threat  requirements 
(greatly  reducing  the  risk  of  technological  or  operational  obsolescence),  while  facilitating 
a  more  robust  and  competitive  defense  industrial  base.  Spiral  development  derives  the 
following  advantages,  primarily  from  effective  risk  management: 

Rapid  Deployment 

By  minimizing  technological  risk,  spiral  development  minimizes  the  likelihood  of 
development  delays.  Spiral  Development’s  shorter  development  cycle  yields  a  more 
rapid  deployment,  which  offers  several  advantages.  First  and  foremost,  greater 
capabilities  are  provided  to  those  that  need  it  the  most:  the  troops  in  the  field.  Faster 
development  and  deployment  of  weapons  allow  a  recognized  deficiency  or  a  (known) 
needed  capability  to  be  filled  quickly.  Second,  the  DoD  would  be  able  to  more  promptly 
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respond  to  new  threats  and  ehallenges.  Deeade-long  development  strategies  are 
inadequate  when  responding  to  today’s  nimble  adversaries  or  ineorporating  rapidly 
ehanging  eommereial  teehnologies.  Finally,  by  emphasizing  short  aequisition  eyeles, 
spiral  development  reinforees  the  use  of  mature  teehnologies,  redueing  the  risk  in 
developmental  projeets. 

Lower  costs 

All  too  often,  the  idea  of  a  new  DoD  weapon,  based  upon  untested  teehnology,  eaptures 
the  imagination  of  military  planners  who  want  to  field  the  next  war  game-ehanger. 
Historieally,  these  extensive  R&D  efforts,  undertaken  at  eonsiderable  eost,  frequently 
resulted  in  sehedule  slips  and  eost  growth.  The  objeetive  of  Spiral  Development  is  to 
reduee  the  program  eosts  by  only  using  mature  teehnologies,  whieh  reduees  the 
possibility  of  delays  while  the  teehnology  matures. 

The  DoD  should  eontinue  to  pursue  the  development  of  high-risk,  high-payoff, 
innovative  teehnologies  (aeknowledging  a  high  failure  rate) — but  these  should  not  be  the 
basis  for  eurrent  developmental  programs. 

Adaptable  Requirements 

With  no  set  end-point  for  development,  spiral  development  undergoes  eonstant 
refinement  to  allow  the  weapon  to  adapt  to  ehanging  DoD  needs.  Although  eaeh  spiral  is 
thoroughly  detailed  with  explieit  goals  and  requirements,  final  speeifieations  for 
subsequent  inerements  are  not  artieulated  until  knowledge  from  the  preeeding  steps  are 
taken  into  aeeount.  Preeeding  inerements  provide  important  information  about  the 
possibilities  of  future  inerements.  Perhaps  an  initially  desired  eapability  is  simply  not 
attainable  with  teehnology  today,  but — ^with  the  development  of  a  new  teehnology — may 
warrant  inelusion  in  a  subsequent  inerement.  Most  importantly,  eonstant  refinement 
greatly  reduees  the  ehanee  of  teehnologieal  or  operational  obsoleseenee.  Constant 
information  sharing  between  the  user,  tester,  developer  and  supporter  ensure  that  a 
projeef  s  eapabilities  properly  represent  the  eurrent  needs  of  the  military.  Rapid 
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deployment  of  technology  ensures  that  weapons  employ  the  most  cutting-edge  and  most 
useful  technology  available  to  the  military. 

Facilitates  a  more  robust  and  competitive  defense  industrial  base 

Spiral  development  would  help  the  DoD  foster  a  more  robust  defense  industrial  base. 
Shorter  development  cycles  would  potentially  allow  the  Department  to  compete  every 
spiral  of  a  program  (depending  on  contractor  performance  in  the  previous  block) — 
encouraging  innovation,  and  driving  down  prices.  Furthermore,  a  greater  number  of 
companies  would  be  able  to  bid  on  DoD  contracts,  as  the  competition  would  rely  on  the 
knowledge  of  mature  technologies  and  not  on  the  promise  of  future  developments.  And, 
it  must  be  emphasized,  this  competition  (at  each  spiral)  could  often  be  at  the  sub-system 
level — at  which  new  technology  frequently  evolves  most  rapidly. 
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III.  Cases 


A.  Predator  Unmanned  Aerial  Vehicle 

Before  the  war,  the  Predator  had  skeptics  because  it  did  not  fit  the  old  ways. 
Now  it  is  clear,  the  military  does  not  have  enough  unmanned  vehicles. 

President  George  W.  Bush,  11  Dec  01 


Background 


The  use  of  unmanned  aerial 


vehieles  (UAVs)  has  beeome 
inereasingly  prevalent  since  the 
turn  of  the  century.  UAVs 
represent  a  transformative 
technology  that  can  be  utilized 
for  a  number  of  vital  missions  in 
which  human  occupation  is 
undesirable  due  to  danger,  length 
of  mission,  or  repetitiveness  of  a  task.  Several  missions  UAVs  currently  undertake 
include  armed  reconnaissance  in  denied  areas,  communication  relay  and  signal  jamming. 


The  Predator  UAV  program  is  one  of  the  most  successful  UAV  programs  to  date  and  is 
an  excellent  example  of  spiral  development.  Although  the  Army  initially  wanted  to 
pursue  the  Predator  program,  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff  designated 
the  Air  Force  as  the  lead  Service.  The  Air  Force  developed  the  Predator  UAV  as  an 
Advanced  Concept  Technology  Demonstration  (ACTD).  ACTDs  are  intended  to  exploit 
mature  and  maturing  technologies  to  solve  important  military  problems  by  having  both 
the  operational  user  and  research  and  development  communities  work  together  to  design 
and  modify  a  system.  The  Predator  ACTD  began  in  November  1993  with  an  ambitious 
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30-month  schedule  for  3  systems  and  10  air  vehieles.  In  July  1995,  the  Predator  was 
flying  operational  reconnaissanee  missions  over  Bosnia  for  Allied  forces  (GAO  1999). 

Program  Overview 

Initially,  the  goal  for  the  Predator  program  was  to  develop  an  inexpensive  UAV  (roughly 
$4  million  each)  that  could  provide  real-time  reeonnaissance,  with  a  twenty-four  hour 
loitering  eapability.  Specifieally,  the  Predator  was  designed  to  orbit  a  target  area  for  an 
extended  period  of  time,  take  high-resolution  photos  of  ground  targets,  and  transmit  them 
back  to  its  operators.  In  contrast  to  the  fully  autonomous  Global  Hawk,  the  Predator  is 
controlled  in  flight  by  a  ground  operator. 

In  the  spring  of  1995,  the  Predator  underwent  a  proof  of  coneept  demonstration  as  it 
participated  in  Roving  Sands,  an  annual  joint  air  defense  exercise.  The  Predator 
performed  so  well  during  this  exereise  that  the  Air  foree  deeided  to  deploy  four  of  the 
UAVs  to  Albania  in  support  of  military  operations  in  Bosnia  in  July  of  1995.  This 
deployment  oecurred  only  1 8  months  after  the  initial  contract  was  awarded.  The  Predator 
program  proved  its  worth  in  Bosnia  by  transmitting  real-time  reconnaissanee  information 
direetly  to  shooters,  considerably  reducing  the  sensor-to-shooter  cyele. 

Based  on  its  success  and  operational  utility  in  Bosnia,  the  decision  was  made  to  forgo  the 
typically  required  System  Development  and  Demonstration  (SDD)  phase  of  aequisition. 
Instead,  the  program  would  be  modified  over  time,  as  teehnieally  and  finaneially  feasible. 
Feedback  from  the  operational  users  would  be  incorporated  incrementally  to  upgrade  the 
eapabilities  of  the  system  (Drew  2005;  Federation  of  American  Scientists  2002) — in 
other  words,  program  managers  were  to  take  a  spiral  development  approaeh. 

In  1996,  the  first  upgrades  to  the  initial  design  were  completed,  primarily  in  response  to 
operational  difficulties  in  Bosnia.  For  example,  the  first  Predators  were  not  equipped 
with  radar  systems  and,  eonsequently,  had  to  fly  beneath  cloud  cover  to  perform  their 
missions.  Flying  at  a  low  level  increased  the  vulnerability  of  the  eraft  to  both  enemy  fire 
and  meehanieal  failure.  Two  of  the  Predators  were  lost,  one  for  eaeh  of  those  reasons. 
Hence,  the  Predator  was  upgraded  with  a  synthetie  aperture  radar  (SAR)  and  Eleetro- 
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Optic al/Infra-Red  sensors.  This  new  sensor  suite  enabled  the  Predators  to  see  through 
clouds,  and,  as  a  result,  it  eould  operate  more  safely  at  higher  altitudes. 

In  July  1996,  Predator  formally  eoneluded  the  30-month  ACTD.  The  system  was 
transferred  to  the  U.S.  Air  Force's  newly  formed  1 1th  Reconnaissance  Squadron,  while 
the  program  transitioned  to  low-rate  initial  produetion  (TRIP)  via  the  formal  military 
aequisition  proeess.  In  August  1997,  less  than  four  years  after  ACTD  initiation,  the 
Predator  entered  full  production  (Office  of  the  Assistant  Secretary  of  Defense  (Public 
Affairs)  1997). 

The  Predator  system  was  used  eontinuously  in  eastern  European  operations  through  the 
1999  Kosovo  air  campaign.  The  system  was  used  to  eolleet  intelligenee  on  targets  and 
refugees,  as  well  as  to  assess  battle  damage.  At  the  same  time,  other  Predator  UAVs 
participated  in  various  interoperability  demonstrations  with  a  Navy  carrier  battle  group 
and  a  Navy  submarine  (The  Defense  Airborne  Reeonnaissanee  Offiee  1997).  Following 
the  sueeess  of  the  first  Predator,  known  as  Predator  A  (referred  to  in  later  variants  as  MQ- 
1  and  RQ-1),  the  feedbaek  and  design  modifications  were  leveraged  in  the  year  2000  to 
create  a  new,  and  considerably  larger  air  vehiele,  known  as  Predator  B  (referred  to  in 
later  variants  as  MQ-9  and  RQ-9). 

Predator  B  began  flying  in  2001  and  is  eonsiderably  larger  than  its  predecessor.  This 
larger  UAV  has  inereased  eapaeities  across  the  board — to  include  a  turboprop  engine, 
whieh  provides  substantially  more  electrical  power  for  the  vehicle’s  payload  and 
inereases  its  transit  speed  and  time  on  station.  In  addition,  the  mission  of  Predator  B  has 
evolved  by  allowing  it  to  earry  out  multiple  missions  simultaneously,  and  independently 
attaek  targets  with  Hellfire  missiles,  GBU-12  laser-guided  bombs,  or  GBU-38  Joint 
Direet  Attaek  Munitions  (see  Figure  9).  The  Predator  ean  provide  eontinuous  monitoring 
of  suspeeted  target  areas,  while  retaining  a  rapid  attaek  eapability  if  a  window  of 
opportunity  arises  (Drew  2005). 
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Figure  9.  Predator  B  with  Hellfire  missiles. 


As  indicated  by  Figure  10,  Predator  A  and  B  differ  considerably  in  their  characteristics 
and  performance.  Predator  B,  a  new  air  vehicle,  leveraged  the  accomplishments  of  the 
spiral  approach  taken  during  initial  developments  of  Predator  A. 


Predator  A 

Predator  B 

Percent  Change 

Approximate 
maximum  takeoff 
weight  (Ihs) 

2,250 

10,500 

467% 

Maximum  Air  Speed 
(knots) 
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220 

200% 

Wingspan  (ft) 

55 

66.0 

120% 

Maximum  payload 
(Ihs) 

Internal 

External 

450 

850 

189% 

300 

3,000 

1000% 

Approximate  ceiling 
(ft) 

25,000 

50,000+ 

200% 

Endurance  (hrs) 

40 

30+ 

-25% 

Primary  mission 

Persistent  ISR  and 
Strike 

Multi-Mission 

ISR  and  Strike 

Figure  10.  Characteristics  of  Predator  A  aud  B  (Geueral  Atomics  2008). 

Later,  the  platform  was  used  extensively  by  the  Central  Intelligence  Agency  for  data 
collection  and  tracking  the  movement  of  suspected  terrorists.  Immediately  after  the  9-11 
attacks,  for  example,  the  Predator  was  deployed  to  Afghanistan  to  provide  intelligence 
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and  a  strike  capability  in  support  of  Operation  Enduring  Freedom.  During  both 
Operation  Iraqi  Freedom  (OIF)  and  Operation  Enduring  Freedom  (OFF),  the  Predator 
family  of  UAVs  has  been  used  extensively  for  surveillance  and  attacks  in  support  of  the 
military  and  CIA  missions  (to  include  Pakistan  (ABC  News  2005),  and  Yemen  (Priest 
2002)). 


Predator  Program  Timeline 


Supported 
Kosovo  Air 
Campaign 


Concept  Deveiopment 


Program  D  3 

Start  I  S 


CD 


H 


3 

3 


1995  1996  1997  1998  2000  2001  2002  2003  2004 

Figure  11.  Predator  Program  Timeline 

Results  and  Conclusions 


The  early,  disciplined-development  approach  of  the  Predator  allowed  the  weapon  to  be 
fielded  quickly.  After  initial  success  in  Bosnia,  the  program  was  transitioned  rapidly 
from  an  ACID  to  a  deployed  weapon.  Due  to  the  accelerated  schedule,  significant 
concurrency — in  production,  testing,  evaluation  and  mission  assessment — took  place. 
The  change  in  the  Predator’s  concept  of  operations,  along  with  user  requirements,  was 
primarily  driven  by  increasing  operational  experience  (Drew  2005). 

The  Predator  program  was  ideally  suited  for  spiral  development.  The  initial  design  was 
relatively  simple  and  stable,  and  all  technologies  used  in  the  program  were  fully  mature. 
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Consequently,  initial  deployment  and  upgrades  were  inexpensive  and  manageable.  By 
fostering  an  open  line  of  eommunieation  between  the  design  team  and  the  operators, 
Predator  evolved  to  meet  the  ehanging  needs  of  the  user.  The  Air  Foree  sueeessfully 
maintained  a  self-imposed  eost  constraint  of  $5  million  for  a  fully  outfitted  Predator  A 
(The  Air  Force  considers  costs  below  $5  million  as  expendable).  This  cost  cap  forced  the 
program  to  make  cost  performance  tradeoffs  and  to  keep  the  program  affordable  (Drew 
2005). 

The  Predator  development  provides  a  clear  case  of  the  adaptability  of  the  spiral 
development  process.  Evolution  occurred,  not  only  in  terms  of  the  technical  spiral 
development  of  the  platform,  but  also  in  regard  to  its  operational  employment  on  the 
battlefield.  Lt.  Gen.  Jack  Hudson,  Commander  of  the  Air  Force  Aeronautical  Systems 
Center,  stated  “77ze  Predator  is  a  great  example  [of  acquisition  flexibility].  Warfighters 
identified  a  need  and  we  [the  Air  Force]  made  incremental  improvements  to  the  Predator 
in  short  order,  sometimes  in  a  matter  of  weeks.  We  [the  Air  Force]  develop  them,  test 
them  and  have  them  in  the  field'  (Kaufman  2008).  Feedback  from  extensive  use  in  OIF 
and  OEF  will  drive  future  development  and  improvements,  enabling  the  most  recent 
technologies  to  meet  the  most  urgent  needs  of  the  user. 
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B.  Acoustic  Rapid  COTS  Insertion  (A-RCI) 


Background 

The  Acoustic  Rapid  COTS  Insertion  (A- 
RCI)  program  displays  how  the  spiral 
development  process  may  also  be  applied  to 
the  modernization  of  legacy  systems  or 
subsystems.  The  impetus  for  this  program 
began  in  the  mid-1990s,  as  the  Navy’s 
submarine  acoustic  superiority  over 
potential  threats  was  rapidly  diminishing. 

This  program  set  out  to  once  again  reassert 
dominance  in  this  field,  but  within  the  post- 
Cold  War  environment  of  shrinking  military  budgets.  Estimates  for  designing  and 
developing  unique  systems  to  meet  the  military  specifications  were  high — $1.5  billion  for 
research  and  development,  and  $90  million  per  ship-set  for  implementation.  The  Navy 
could  not  afford  this  level  of  investment,  and  instead  chose  to  pursue  an  incremental 
improvement  strategy.  Overall,  the  A-RCI  program  has  been  heralded  as  an  unbridled 
success  by  the  Navy  that  has  brought  about  “astounding  cost  reduction,  dramatic 
improvement  in  technical  performance,  and  an  acquisition  model  that  might  have  broad 
applicability  across  the  DoD”  (3)(Boudreau  2006). 

Program  Description 

The  A-RCI  program,  designated  AN/BQQ-10,  was  a  four-phase  program  for 
transforming  three  legacy  submarine  sonar  systems  (AN/BSY-1,  AN/BQQ-5,  and 
AN/BQQ-6)  into  a  single  system.  The  program’s  acquisition  strategy  would  utilize  more 
capable  and  flexible  Commercial-off-the-shelf  (COTS)  components  as  the  basis  for  a 
sonar  system  that  is  far  more  capable  and  flexible  than  earlier  designs.  The  program 
would  also  implement  a  Modular-Open-Systems  Approach  (MOSA)  to  reduce  future 
implementation  costs.  Using  this  configuration,  this  system  would  allow  a  “plug-and- 
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play”  format  that  would  allow  seamless  and  effieient  upgrades  to  oceur  frequently,  with 
little  or  no  impaet  on  submarine  scheduling — making  it  an  ideal  candidate  for  spiral 
development  (Boudreau  2006). 

The  A-RCI  program’s  spiral  development  approach  enables  the  Navy  to  update  the 
hardware  on  a  two-year  cycle,  while  the  software  is  updated  annually  to  create  a  new 
software  baseline.  Using  this  approach,  the  Navy  can  continue  to  efficiently  leverage  the 
advances  in  the  dynamic  commercial  technology  market  to  consistently  provide  the  fleet 
with  near-state-of-the-art  processing  capability  (Rosenberger  2005). 

The  initial  A-RCI  technology  insertions  eliminated  most  of  the  custom  cards  used  in  the 
system’s  initial  configuration.  This  immediately  and  dramatically  improved  the 
performance  of  the  operator’s  displays,  increased  the  system’s  reliability,  yet  kept 
development  and  acquisition  costs  low.  Moreover,  programs  for  the  hardware 
components  could  now  be  written  in  a  higher-level  language,  instead  of  at  the  tedious 
assembly  level  previously  required.  Programmers  could  now  devote  more  time  to  the 
system’s  performance,  instead  of  dealing  with  details  of  the  hardware  interface.  With 
subsequent  technology  insertions  in  2002  and  2004,  the  program  was  able  to  transition  to 
the  then-current  commercial  processors,  the  Intel  XEON-based  servers  running  at  even 
higher  clock  speeds  (Kerr  2004). 

Results  and  Conclusions 


The  A-RCI  program  proved  that  the 
spiral  development  process  could  be  an 
effective  means  to  upgrade  legacy 
systems.  Continuous  improvements, 
through  incremental  spirals  that  follow  a 
knowledge-based  approach,  allow  for 
significant  increases  in  capabilities  while 
keeping  costs  low.  Specifically,  through 
2004,  using  its  spiral  technology  insertion 


approach,  the  A-RCI  program  enabled  a  lOx 
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increase  in  system  throughput  and  an  86%  reduetion  in  hardware  eost  per  billion  floating 
point  operations  per  seeond,  in  a  six-year  period  (Kerr  2004).  As  a  result  of  the 
inereasing  reliability  of  the  eommereial  systems,  the  Navy  introdueed  a  pilot  program  to 
test  the  eoncept  of  a  Maintenanee-free  Operating  Period  (MFOP)  for  the  A-RCI  program. 
The  pilot  program’s  goal  was  to  eliminate  the  need  for  maintenanee  of  the  A-RCI  system 
while  the  submarine  was  underway;  all  maintenance  would  be  deferred  to  the  next  in-port 
period.  Of  the  four  submarines  that  partieipated  in  the  testing  over  the  eourse  of  one 
year,  no  maintenanee  was  required  in  any  of  the  four — exeeeding  everyone’s 
expeetations.  Furthermore,  system  operational  availability  improved.  The  mean-time-to- 
repair  deereased  by  an  order  of  magnitude,  from  20  minutes  to  2  minutes,  using  the 
embedded  spares  approaeh  (Kerr  2006). 

The  A-RCI  program  addressed  the  ehallenge  of  modernizing  the  Navy’s  sonar  eapability 
while  under  severe  budgetary  pressure.  With  its  innovative  spiral  approaeh,  the  Navy 
was  able  to  signifieantly  improve  the  fleet’s  sonar  performanee  by  leveraging  the  rapid 
advanees  in  eommereial  eomputer  teehnology,  while  at  the  same  time  keeping 
development  and  support  eosts  low.  Furthermore,  the  modular  open  systems  approaeh 
allowed  fielded  systems  to  be  updated  seamlessly  and  in  a  eost-effective  manner.  The 
Navy  was  also  able  to  put  in  plaee  an  extremely  effective  Performanee-based  Logisties 
(PBL)  contraet  with  the  system  developer.  Leveraging  the  two-year  spiral  upgrade  cyele, 
the  eontraetor  has  developed  an  innovative  approaeh  to  minimize  the  required  inventory 
while  exeeeding  the  fleet’s  requirements  and  steadily  reducing  the  costs  of  repair  by  an 
estimated  32%,  based  on  the  then-eurrent  eosts  (Gansler  2006).  The  eombination  of  these 
strategies — spiral  development,  COTS,  and  MOSA — ereated  a  synergism  that  redueed 
development  eyeles  to  a  fraetion  of  their  former  figure. 
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C.  Global  Hawk 


Background: 

As  the  mission  of  the 
U.S.  armed  forces 
continues  to  evolve  in  the 
post-Cold  War  era,  the 
military  has  relied  more 
heavily  upon  the  use  of 
Command,  Control, 

Communications, 

Computers  and 
Intelligence  (C4I)  to  act 
as  a  force  multiplier.  An  important  component  of  C4I  is  unmanned  aerial  vehicles 
(UAVs).  The  Global  Hawk  RQ-4A  and  B  variants  are  fully  autonomous  reconnaissance 
UAVs  that  have  been  used  extensively  in  both  Iraq  and  Afghanistan.  The  military  chose 
the  Global  Hawk  as  one  of  the  test  beds  to  assess  the  feasibility  of  the  spiral  development 
process  in  light  of  the  military’s  historic  difficulty  in  developing  UAVs.  As  noted  by  one 
study,  “the  United  States  has  seen  a  three-decade-long  history  of  poor  outcomes  in 
unmanned  aerial  vehicle  (UAV)  development  efforts.  UAV  and  tactical 
surveillance/reconnaissance  programs  have  a  history  of  failure  involving  inadequate 
integration  of  sensor,  platform,  and  ground  elements,  together  with  unit  costs  far 
exceeding  what  operators  have  been  willing  to  pay”  (Drezner  2002b).  In  the  case  of  the 
Global  Hawk,  the  military  desired  the  development  of  a  feasible  concept  vehicle  as 
quickly  as  possible. 

The  Global  Hawk  RQ-4A,  also  identified  as  the  Conventional  High  Altitude  Endurance 
(CONV  HAE)  or  Tier  11+  UAV,  was  the  DoD’s  attempt  to  build  an  unmanned,  fully 
autonomous,  reconnaissance  air  vehicle.  Global  Hawk  was  envisioned  as  the  primary 
platform  for  missions  requiring  long-range  deployment,  wide-area  surveillance,  and  a 
long  sensor  dwell-time  over  the  target  area.  Global  Hawk  was  to  be  deployable  from 


29 


outside  the  theater  of  operation,  and  to  immediately  provide  extended  on-station  time  in 
low-  to  moderate-risk  environments  in  order  to  provide  imagery  of  high-threat  loeations 
using  electro-optical  (EO),  infra-red  (IR),  and  synthetic  aperture  radar  (SAR)  sensors. 
Unlike  prior  UAVs,  the  Global  Hawk  was  outfitted  with  a  variety  of  survivability 
features,  including  the  capability  to  operate  at  high  altitudes  and  with  built-in  self-defense 
measures  (The  Defense  Airborne  Reconnaissance  Office  1997). 

Program  Description: 

Global  Hawk  was  initially  developed  as  an  Advanced  Concept  Technology 
Demonstration  (ACTD)  program.  As  an  ACTD,  the  primary  purpose  of  the  program  was 
to  leverage  technology  demonstrated  in  real-world  situations  to  evaluate  its  viability  as  a 
full-fledged  military  acquisition  program.  Because  this  program  was  designed  from  the 
onset  to  adhere  to  spiral  development  principles,  the  most  important  goals  were  to  remain 
within  the  required  $10  million  per  unit  flyaway  price  and  to  keep  the  program  on 
schedule.  The  plan  was  to  use  the  first  spiral  to  provide  a  base-line  capability,  while 
using  additional  spirals  to  rapidly  insert  additional  capabilities  into  production  when 
ready.  To  accomplish  these  goals,  the  program  office  was  willing  to  allow  competing 
firms  to  trade  all  other  performance  goals  as  necessary  to  meet  cost  and  schedule 
parameters  (Drezner  2002a;  Johnson  2002). 

The  Defense  Research  Projects  Agency  (DARPA)  released  the  Solicitation  for  this  UAV 
project  in  April  1994  and  awarded  the  Teledyne  Ryan  team  the  contract  in  May  1995. 

The  first  Global  Hawk  RQ-4A  prototype  completed  its  first  flight  on  February  28,  1998. 
After  initial  flight  testing,  a  second  Global  Hawk  was  produced  in  November  1998  that 
included  a  sensor  payload.  Trials  for  its  military  application  began  in  1999.  The  rest  of 
that  year  saw  several  setbacks  for  the  Global  Hawk  program,  as  the  second  prototype  was 
lost  due  to  “an  erroneous  flight  termination  test  signal  that  had  been  sent  from  Nellis 
AFB,  Nevada;  while  a  high-speed  taxi  accident  at  Edwards  AFB  set  back  AV-3  in 
September  1999”  (Roberts  2006).  Despite  these  setbacks,  the  Global  Hawk  maintained 
its  initial  development  schedule  (presented  below  in  Figure  12).  In  March  2001,  based  on 
the  successful  demonstrations  and  operational  deployments  of  demonstrator  aircraft,  the 
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DoD  approved  the  Global  Hawk  for  a  eoneurrent  start  of  system  development  and  low- 
rate  initial  produetion  of  six  air  vehieles.  At  that  time,  the  Air  Foree  planned  both  to  use 
spiral  development  to  develop  more  advaneed  eapabilities  as  well  as  to  aequire  63  air 
vehieles  (GAO  2004). 


Figure  12.  Global  Hawk’s  Initial  Development  Schedule. 


Following  9/11,  the  existing  fleet  of  Global  Hawks  was  hurried  into  operational  service 
for  the  initiation  of  Operation  Enduring  Freedom  (OEF).  It  would  also  be  used 
extensively  in  Operation  Iraqi  Ereedom  (OIE).  While  still  in  the  development  phase,  the 
Global  Hawk  would  go  on  to  log  over  3,000  flight  hours,  a  majority  of  that  number  being 
operational  missions  in  support  of  OEE  and  OIE.  The  Global  Hawk  platform  has  been  in 
continuous  service  since  its  initial  operational  status  and  continues  to  serve  in  both  Iraq 
and  Afghanistan.  Overall,  the  Global  Hawk  took  little  more  than  six  years  to  develop 
from  initial  solicitation  to  first  operational  fielding  of  the  system  (Northrop  Grumman 
Global  Hawk  Program  2006). 

During  its  service  in  combat  operations,  the  Global  Hawk  RQ-4A  provided  the  military 
with  a  vast  amount  of  real-time  intelligence. 

With  just  one  air  vehicle  deployed,  the  system  was  credited  with  identifying  38%  of  Iraq ’s 

armor  and  55%  of  the  time-sensitive  air  defense  targets  using  electro-optical  (EO), 
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infrared  (IR),  and  synthetic  aperture  radar  (SAR)  images  to  target  Iraqi  forces.  These 
early  combat  deployments  demonstrated  the  effectiveness  of  carrying  multiple  sensor 
capabilities  on  the  same  platform.  (Coale  2006) 

Following  the  RQ-4A’s  operational  sueeess,  the  Air  Foree  deeided  to  design  a  new, 
larger  and  more  eapable  variant  of  the  Global  Hawk,  known  as  the  RQ-4B.  Originally, 
the  RQ-4B  eomponents  were  to  be  90%  eompatible  with  the  A  model.  Desiring  even 
more  eapability,  the  Air  Foree  deeided  to  design  a  signifieantly  larger  B  variant. 
Ultimately,  the  B  variant,  when  compared  to  the  A,  could  carry  a  50%  larger  payload,  fly 
for  two  hours  longer  and  retain  the  approximate  10,000nm  range  (Figure  13,  below, 
compares  the  key  characteristics  of  the  two  aircraft).  The  development  of  the  RQ-4B 
project  was  to  be  funded  with  the  original  budget  for  the  4A;  however,  at  the  same  time, 
the  Air  Force  relaxed  the  unit  flyaway  cost  requirement. 


Key  characteristics 

RQ-4A 

RQ-4B 

Payload  capacity 

2,000  pounds 

3,000  pounds 

Take-off  weight 

26,750  pounds 

32,250  pounds 

Wingspan 

116.2  feet 

130.9  feet 

Fuselage  length 

44.4  feet 

47.6  feet 

Endurance 

31  hours 

33  hours 

Time  at  60,000  feet 

14  hours 

4  hours 

Average  speed  at 

60,000  feet 

340  knots 

310  knots 

Approximate  range 

10,000  nautical  miles 

10,000  nautical  miles 

Figure  13.  Key  Characteristics  of  the  RQ-4A  and  RQ-4B  (GAO  2004) 
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As  the  focus  of  Global  Hawk  acquisition  shifted  from  Model  A  to  Model  B,  the  program 
was  restructured  in  March  2002.  The  new  strategy  included  51  air  vehicles;  of  these  51 
air  vehicles,  7  were  to  be  constructed  as  RQ-4As  and  44  built  as  RQ-4Bs  (GAO  2004). 
The  development  period  was  extended  from  7  years  to  12  years,  while  the  procurement 
period  was  shortened  from  20  years  to  1 1 .  Asa  result,  the  funding  profile  changed 
dramatically — the  RDT&E  funding  requirements  increased,  and  are  now  spread  over  a 
longer  (12  yrs)  development  timeline.  Conversely,  in  order  to  accommodate  a  shorter  (11 
yrs)  procurement  period,  the  procurement  funding  requirements  were  compressed 
radically  (Henning  2005).  In  December  2002,  the  program  was  again  restructured  as  a 
result  of  the  Air  Force’s  request  to  change  the  Global  Hawk’s  mission  configuration; 
instead  of  buying  all  RQ-4Bs  with  multiple  intelligence  capability,  the  RQ-4Bs  would 
now  have  a  mix  of  multi-mission  and  single-mission  capabilities.  Additionally,  these  two 
restructurings  increased  low-rate  initial  production  quantities  to  19  (subsequently 
increased  to  20)  air  vehicles:  7  RQ-4As  and  12  (now  13)  RQ-4Bs  (GAO  2004).  As  of 
2006,  development  and  production  of  RQ-4A  was  complete.  RQ-4B  currently  remains  in 
production. 


Global  Hawk  Program  Timeline 


1994 


1995 


1996 


1997 


1998  1999  2000  2001 


2002 


2003  2004 


Figure  14.  Global  Hawk  Program  Timeline 
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Results  and  Conclusions: 


Many  independent  commentators  have  regarded  the  Global  Hawk  RQ-4A  program  as  a 
great  success.  It  is  the  first  automated  air  vehicle  to  receive  the  Federal  Aviation 
Administration’s  national  Certificate  of  Authorization,  allowing  it  to  fly  anywhere  in  U.S. 
airspaces  without  prior  authorization.  The  vehicle  is  also  the  “first  unmanned  aerial 
vehicle  to  achieve  a  military  airworthiness  certification”  (Northrop  Grumman  Global 
Hawk  Program  2006).  The  Global  Hawk  RQ-4A  was  the  first  UAV  to  fly  across  the 
Atlantic  Ocean  and  later  became  the  first  UAV  to  fly  across  the  Pacific  Ocean. 

The  success  of  the  Global  Hawk  RQ-4A  program  validated  the  spiral  development 
process;  despite  notable  setbacks,  the  program’s  flexibility  allowed  the  program  to 
develop  with  only  modest  changes  to  the  initial  budget  and  time  constraints.  The  Global 
Hawk  program  effectively  shifted  requirements  between  spirals  to  avoid  development 
bottlenecks  stemming  from  delays  in  technological  maturity.  Spiral  development  also 
allowed  the  program  to  be  accelerated  quickly  to  meet  a  new  challenge,  principally  OFF. 
Finally,  Global  Hawk  proved  that  incremental  deployment  of  capabilities  was  feasible. 

The  restructured  Global  Hawk  program  eventually  faced  significant  cost  and  schedule 
difficulties.  The  program’s  problems  stemmed  principally  from  two  sources;  an 
unrealistically  low  initial  estimate  of  cost  and  the  RQ-4B  program  restructuring.  The  first 
problem  arose  because  no  technical  surveys  were  undertaken  to  understand  the  true  costs 
and  timeline  needed  for  the  capabilities  requested.  The  costs  for  the  program  were,  in 
large  part,  based  on  what  the  Air  Force  was  willing  to  pay  for  the  Global  Hawk’s 
theoretical  capabilities.  The  second  problem  arose  from  uncontrolled  requirements  creep, 
without  a  re-baselining  of  the  project.  For  example,  the  program  insisted  on  including  a 
capability,  known  as  Automatic  Contingency  Generation  (ACG),  in  the  first  baseline 
(instead  of  the  first  production  lot  as  originally  planned).  The  ACG  is  a  software 
program  to  autonomously  re-route  the  air  vehicle  during  an  inflight  emergency  to  an 
alternate  airfield,  while  avoiding  no-fly  zones.  However,  the  complexity  of  the  ACG  was 
not  fully  understood,  and,  consequently,  a  significant  amount  of  additional  time  was 
spent  trying  to  field  the  ACG  capability  in  the  first  baseline.  As  a  result,  the  fielding  of 
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the  first  production  hardware  and  training  courses  were  both  delayed  (Coale  2006).  This 
capability  could  have  easily  been  deferred  to  a  future  software  release. 

It  may  be  argued  that  the  Global  Hawk  program  ceased  to  follow  a  spiral  development 
path  when  the  decision  was  made  to  significantly  increase  the  size  (it  was  50%  larger) 
and  to  enhance  the  capabilities  of  the  second  Global  Hawk  variant,  the  RQ-4B,  while 
eliminating  the  cost  targets.  Despite  the  commonality  in  names,  the  RQ-4B  version  was 
virtually  a  new  development  that  only  shared  broad  characteristics  with  the  A  variant. 

The  RQ-4B  is  a  classical  case  of  requirements  creep;  as  a  result,  as  of  September  2007, 
the  R&D  cost  increased  over  270%  (GAO  2008).  Additionally,  as  indicated  by  RAND  in 
one  study  on  the  effectiveness  of  the  ACTD  process  and  the  Global  Hawk:  “The 
constrained  budget  and  tight  schedule  of  the  ACTD  does  not  address  the  complete 
development  needs  of  a  major  defense  system.  An  ACTD  is  focused  on  demonstrating 
military  utility,  not  the  operationalization  of  a  system”(Drew  2005).  As  a  result,  lifecycle 
costs,  with  all  of  the  support  implications,  were  not  a  major  consideration  during  the 
ACTD  portion  of  the  Global  Hawk  program. 

Even  with  its  initial  problems,  which  were  not  associated  with  the  process  of  spiral 
development  itself,  the  Global  Hawk  RQ-4A  experienced  no  overall  cost  growth,  nor 
were  there  any  major  delays  in  its  scheduling.  The  results  for  the  RQ-4B  are  less  clear — 
as  cost  growth  in  the  Global  Hawk  program  was  considerable  with  regards  to  the 
redesigned  RQ-4B.  A  simple  analysis  of  the  situation  by  Michael  Sullivan,  GAO  director 
of  acquisition  management,  is  “They  were  able  to  build  the  A  model  pretty  well.  But  they 
added  requirements  that  have  now  put  them  behind  in  cost  and  schedule”  (Erwin  2006). 
Originally,  the  RQ-4B  was  designed  only  to  be  a  slightly  larger  and  more  capable  version 
of  the  RQ-4A,  at  a  small  increase  in  price.  Instead,  however,  the  B  model  grew 
significantly  in  both  size  and  cost. 

The  RQ-4A  followed  the  spiral  development  process  along  with  a  proper  knowledge- 
based  foundation.  Although  the  spiral  development  process  was  not  implemented 
flawlessly,  this  test  bed  provides  important  information  vital  for  future  implementation  of 
this  policy.  Notably,  the  experience  proved  that  the  process  was  able  to  overcome  the 
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overly  optimistic  initial  expectations  to  deliver  a  widely  praised  system  that  was  both  on 
time  and  on  budget.  A  testament  to  the  DoD’s  admiration  of  the  program  was  the 
subsequent  decision  for  a  redesign  of  the  RQ-4B  into  an  even  a  larger  and  more 
sophisticated  model  than  originally  envisioned.  Unfortunately,  this  overhaul  was  not 
properly  planned,  and  the  program  ceased  to  follow  a  knowledge-based  approach  to 
development.  The  perils  of  pursuing  a  development  project  without  sufficient  knowledge 
are  highlighted  by  the  ballooning  cost  of  the  program  and  the  delayed  delivery  schedule. 
Measured  management  oversight  is  needed  to  restrain  requirements  creep.  Finally,  DoD 
weapons  programs  must  learn  to  accept  interim  capabilities  that  will  be  increased 
incrementally. 
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D.  Littoral  Combat  Ship 


Background 


The  focus  of  defense  in  the 
twenty-first  century  has 
shifted  away  from  the 
traditional  threats  posed 
during  the  Cold  War  towards 
unpredictable  and  asymmetric 
threats.  The  U.S.  Navy  now 
requires  more  mobile  and 
adaptive  forces  to  respond  to  a 
variety  of  new  threats  and  operational  goals.  One  prominent  new  concern  is  the  ability  to 
control  various  strategic  points  of  interest  along  coastal  waterways  and  inland  rivers, 
facilitating  green  water  operations. 

To  address  these  coastal  operations  in  green  water,  the  Navy  has  chosen  to  build  a  new 
surface  combatant,  known  as  the  Littoral  Combat  Ship  (LCS).  The  mission  of  the  LCS  is 
to  counter  diverse  “asymmetric”  threats  such  as  coastal  mines,  submarines,  global  piracy, 
and  terrorists.  Secondary  missions  include  homeland  defense,  maritime  intercept 
operations,  and  support  of  special  operations  forces.  The  LCS  has  the  capability  to 
perform  tasks  such  as  intelligence  gathering,  scouting,  and  ground  combat  support  using 
helicopters  and  UAVs.  The  LCS  was  designed  to  share  tactical  information  with  other 
Navy  aircraft,  ships,  submarines,  and  joint  units.  This  platform,  optimized  for  shallow 
water,  principally  operates  within  100  miles  of  shore  to  protect  coastlines  but  retains  the 
capacity  to  be  deployable  across  the  ocean. 

The  Navy’s  design  concept  for  the  LCS  consists  of  two  distinct  parts:  the  ship  itself  and 
the  mission  package  it  carries  and  deploys.  The  ship  is  referred  to  as  the  “seaframe”  and 
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consists  of  the  hull,  command  and  control  systems,  launch  and  recovery  systems,  and 
certain  core  systems  like  the  radar  and  gun.  The  mission  packages  are  intended  to  be 
modular  in  that  they  will  be  interchangeable  on  the  seaframe.  Each  mission  package — 
based  upon  the  use  of  a  modular,  open  systems  architecture  to  add  further  flexibility  and 
capability  to  the  design — will  consist  of  systems  made  up  of  manned  and  unmanned 
vehicles  and  the  subsystems  these  vehicles  use  in  their  missions  (O'Rourke  2008b).  An 
ECS  ship  will  have  the  ability  to  quickly  adapt  to  changing  mission  requirements  by 
swapping  mission-specific  modules  that  include  hardware,  additional  systems 
components  and  personnel  (Defense  Industry  Daily  2008).  Being  reconfigurable  allows 
the  ECS  to  preserve  a  single  mission  focus  while  retaining  the  ability  to  change  that 
mission  on  demand.  The  ship  retains  its  core  capabilities  regardless  of  the  installed 
module. 

The  Navy  pursued  a  highly  aggressive  development  program  for  the  ECS,  which  sought 
to  significantly  reduce  the  time  needed  to  design  and  build  a  surface  combatant  ship. 
These  gains  would  accrue  from  the  use  of  a  Commercial-off-the-Shelf  platform  (the  basis 
for  the  ship’s  hull).  Cost  as  an  Independent  Variable  (CAIV)  (allowing  capabilities  trade 
while  enforcing  spending  caps),  and  spiral  development — to  fulfill  the  Navy’s  strong 
desire  to  introduce  new  capabilities  in  later  development  spirals,  when  the  requirements 
demanded  it  (Hamilton  2006).  In  spite  of  this  ambitious  attitude,  the  ECS  program  (to 
date)  has  been  a  highly  complex  endeavor  and  has  been  plagued  with  difficulties. 

The  DoD  awarded  the  first  ECS  contracts  to  both  Eockheed  Martin  and  General 
Dynamics  in  May  of  2004.  Their  teams  were  asked  to  prepare  initial  designs  which 
would  be  further  down-selected  for  the  Detailed  Design  &  Construction  phase  of 
acquisition  (both  teams  used  Commercial  and  foreign  off-the-shelf  designs — and 
subcontractors).  Preliminary  designs  gave  the  ECS  a  displacement  of  roughly  3,000  tons, 
or  half  of  a  U.S.  Coast  Guard  Cutter;  a  maximum  speed  of  roughly  45  knots,  or  nearly 
50%  faster  than  other  navy  surface  combatants;  and  a  reduced  crew  requirement  of  only 
75  sailors,  compared  with  the  more  than  200  for  a  comparable  Navy  Erigate.  In  addition, 
the  Navy  was  seeking  to  procure  ships  in  numerous  spirals  (called  flights);  each  flight 
could  then  have  the  latest  technologies  and  available  improvements  by  taking  advantage 
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of  the  spiral  development  approach  to  improve  the  platform  design  over  time  (Drew 
2005;  PEO  Ships  2008).  The  combination  of  the  spiral  development  approach,  along 
with  the  use  of  mission-specific  modules  for  flexibility  and  adaptability,  makes  the  ECS 
program  notably  different  from  any  other  Navy  ship-building  program. 

Program  Description 

The  Navy’s  strategy  was  to  break  the  ECS  acquisition  into  “flights”  for  the  seaframe  and 
“spirals”  for  mission  packages  in  order  to  develop  improvements  while  fielding 
technologies  as  they  become  available.  The  initial  flight  of  ships,  referred  to  as  Elight  0, 
was  intended  to  serve  two  purposes:  to  provide  a  limited  operational  capability  and  to 
provide  input  to  the  Elight  1  design  through  experimentation  with  operations  and  mission 
packages.  Elight  1  was  to  provide  more  complete  capabilities,  but  would  not  serve  as  the 
sole  design  for  the  planned  buy  of  more  than  50  ECSs.  Elight  0  was  planned  to  consist  of 
four  ships  of  two  different  designs  and  would  be  procured  in  parallel  with  the  first 
increment  of  mission  packages — Spiral  Alpha  (GAO  2005). 

Consistent  with  this  spiral  approach  to  development  of  the  ECS,  in  EY05  Congress 
approved  the  Navy’s  plan  to  fund  the  construction  of  the  first  two  ECS  seaframes  using 
research  and  development  funds  as  opposed  to  shipbuilding  funds.  In  December  of  2004, 
Eockheed  Martin  was  awarded  a  contract  for  the  Detailed  Design  &  Construction  phase 
for  ECS  1. 

In  October  of  2005,  an  additional  contract  for  Detailed  Design  and  Construction  was 
awarded  to  General  Dynamics  for  ECS  2.  The  Navy’s  acquisition  strategy  was  to 
develop  and  build  the  first  spiral  of  15  ships,  known  as  Elight  0,  using  these  two  designs. 
Subsequent  flights  could  then  be  competed  between  them.  While  specifics  of  the 
competition  have  yet  to  be  determined,  it  is  probable  that  this  acquisition  would  not  be  a 
winner-take-all  scenario;  the  firms  would  likely  have  an  opportunity  to  compete  for 
construction  at  each  additional  flight,  leading  to  the  possibility  that  the  winner  of  the 
design  competition  may  not  be  the  winner  of  all  the  construction  work  (Jean  2007). 
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Each  team  had  a  very  different  design  approaeh  for  their  version  of  the  ECS,  with 
Eoekheed  Martin’s  design  based  on  what  is  known  as  a  semi-planing  monohull,  and 
General  Dynamies’  design  based  on  an  aluminum  trimaran  (Elnited  States  Navy  2008). 

In  EY2006,  Congress  funded  the  proeurement  of  ECSs  2,  3,  and  4,  in  addition  to 
establishing  a  $220  million  per  unit  proeurement  eost  limit  on  the  fifth  and  sixth  ECS 
seaframes — ^plus  adjustments  for  inflation  and  other  sueh  eost  fluetuations.  In  this 
budget,  however.  Congress  required  that  the  aequisition  of  future  ECSs  be  eontingent 
upon  the  Navy  eertifying  that  a  stable  design  for  the  ECS  platform  had  been  aehieved 
(O'Rourke  2008a). 

The  ECS  program  was 
having  severe  diffieulties 
staying  on  sehedule  and  on 
budget  due  to  signifieant 
requirements  and  design 
ehanges  and  the  desire  to 
ineorporate  them  into 
Elight  0.  In  spite  of  these.  Congress  eontinued  to  support  the  program,  and  in  EY07 
funded  the  proeurement  of  ECS  5  and  6.  In  response  to  a  Navy  request.  Congress  also 
amended  the  existing  unit  proeurement  eost  eap  for  all  ECS  ships  (beginning  with  the 
fifth)  from  $220  million  to  $460  million,  but  this  ehange  alone  appeared  not  to  be 
enough.  In  part  because  of  the  aggressive  sehedule,  along  with  other  requirements  for  the 
ECS  program,  the  program  experieneed  several  delays  in  design,  development  and 
produetion.  On  the  ECS  1  ship,  repeated  and  large  eost  inereases  eaused  the  Navy  to 
issue  a  stop-work  order  for  ECS  3  ship  in  January  2007  (O'Rourke  2008a). 

In  Mareh  of  2007,  the  program  was  restruetured,  but  ECS  5  and  6  were  subsequently 
eaneeled.  Congress  reasoned  that  this  funding  eould  be  used  to  eover  eost  overages  on 
existing  ECS  eontracts.  The  Navy  announeed  that  the  existing  stop-work  order  on  ECS  3 
would  be  reseinded,  onee  Eoekheed  Martin’s  eontract  was  restruetured  from  a  eost-plus 
to  a  fixed-priee,  ineentive-fee  eontract.  Additionally,  General  Dynamies’  eontraets  were 
also  to  be  restruetured  to  fixed-priee,  ineentive-fee  eontraets.  The  Navy  reiterated  that  it 
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would  use  an  operational  evaluation  to  ehoose  the  final  design,  and  subsequent  units 
would  be  proeured  using  a  full-and-open  eompetition  proeess. 


LCS  Program  Timeline 
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Figure  15.  LCS  Program  Timeline. 

Despite  the  Navy’s  noble  efforts  to  salvage  the  ships  that  remained  under  the  LCS 
program,  set-baeks,  sehedule  delays,  and  eost  overruns  eontinued  to  plague  the  program. 
The  Navy  and  Loekheed  Martin  eould  not  reaeh  an  agreement  on  how  to  restrueture  the 
aequisition.  In  light  of  these  efforts,  only  one  month  after  the  announeement  of  a 
program  restrueturing,  LCS  3  was  terminated.  To  preserve  the  spiral  intent  of  the 
program,  Loekheed  was  permitted  to  eontinue  the  development  of  teehnologies  that  were 
to  be  ineluded  with  LCS  3  with  the  hope  that  they  eould  be  integrated  into  future  LCS 
ships  built  by  Loekheed.  Finally,  General  Dynamies,  like  Loekheed,  eould  not  reaeh  an 
agreement  with  the  Navy  on  how  to  suoeessfully  re-negotiate  their  eontraet.  As  a  result, 
LCS  4  was  also  eaneeled  in  November  of  2007.  In  FY2008,  Congress  funded  the 
proeurement  of  one  more  LCS  (ealled  LCS  5,  but  it  would  aetually  be  the  third  ship),  and 
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notably  reduced  the  Navy’s  FY  funding  request  for  the  program  overall,  while  amending 
the  LCS  seaframe  per-unit  cost  cap  to  $460  million  per  ship  for  all  ships  procured  in 
FY2008  and  beyond  (O'Rourke  2008b). 

Results  and  Conclusions 

From  its  inception,  the  Navy’s  LCS  Program  had  even  more  challenges  than  the  typical 
DoD  Acquisition  Category- 1  program.  The  resultant  program  did  not  address  the 
challenges  well  and  has  been  a  difficult  undertaking  thus  far;  it  can  not  be  considered  a 
well-managed  program.  We  believe  the  root  causes  were  an  overly  aggressive  schedule 
coupled  with  unrealistic  cost  estimates.  For  example,  overly  optimistic  cost  estimates  on 
LCS  1  and  LCS  3  underestimated  the  changes  that  would  be  required  to  meet  military 
requirements,  and  drove  subsequent  cost  increases  from  $2 16m  in  FY05  to  $531  in 
FY09.  These  increases  ultimately  lead  to  the  stop-work  order  on  LCS  3.  Figure  16 
depicts  cost  growth  estimates  for  the  LCS  1  and  LCS  2  sea  frames. 
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$215.5 

$274.5 
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LCS  2 

$213.7 

$278.1 

$507 

30% 
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Figure  16.  LCS  Cost  Growth  Estimates  (O'Rourke  2008b). 

The  schedule  was  equally  unrealistic.  A  typical  DoD  Acquisition  Category- 1  program 
takes  roughly  14  years  from  inception  to  production.  The  LCS  attempted  to  accomplish 
this  feat  in  just  2  years.  Furthermore,  the  proposed  LCS  designs  were  based  upon  the 
assumption  that  the  ships  would  be  based  on  proven  Commercial-off-the-Shelf  (COTS) 
designs.  In  reality,  these  COTS  design  did  not  meet  all  of  the  detailed  Navy 
specifications;  but,  rather  than  meeting  these  incrementally,  the  Navy  insisted  on  meeting 
all  of  them  for  LCS  1  and  2. 

Much  of  the  difficulty  in  meeting  Navy  specifications  has  been  attributed  to  the 
application  of  an  updated  version  of  the  Naval  Vessel  Rules  (NVR),  which  are 
construction  standards  for  shipbuilding  created  by  Naval  Sea  Systems  Command 
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(NAVSEA)  and  the  American  Bureau  of  Shipping  (ABS).  These  rules,  which  are 
frequently  updated,  address  many  key  aspects  of  ship  design,  such  as  safety,  stability, 
structural  integrity,  propulsion,  etc.  In  the  case  of  the  Lockheed  Martin-designed  LCS  1, 
the  newest  version  of  the  NVR  was  not  released  until  after  its  original  design  was 
completed  (O'Rourke  2008b).  Figure  17  demonstrates  the  major  discrepancies  between 
the  draft  version  of  the  NVR  (as  circulated  during  the  design  phase  of  LCS  1)  and  the 
actual  version  that  was  released. 
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Part  0  -Intro/General  Provisions 

166 

1537 

9 
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713 

11 

Part  1  -Hull  and  Structure 

140 

1042 

4 

220 

1643 

6 

Part  2  -Propulsion  and 

Maneuvering 

238 

2265 

2 

628 

6386 

7 

Part  3  -Electrical  Systems 

270 

2383 

5 

417 

2967 
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Part  4  -Control  and  Navigation 

210 

1680 

4 

233 

2229 

5 

Part  5  -Auxiliary  Machinery  Sys 

199 

1409 

6 

765 

9223 

15 

Part  6  -Habitability  and  Outfit 

421 

2217 

14 

156 

2410 

16 

Part  7  -Military  Environment 

10 

24 

3 

17 

19 

3 

Part  8  -Materials  and  Welding 

650 

2704 

18 

587 

3845 

20 

Total 

2,304 

15,261 

65 

3,207 

29,435 

88 

Figure  17.  Comparison  of  May  2004  and  February  2004  NVR  Specifications  (Moosally  2007). 


While  both  General  Dynamics  and  Lockheed  Martin  worked  hard  to  negotiate  these 
standards  and  attempted  to  integrate  them  over-time,  the  ABS  and  the  Navy  were  unable 
and/or  unwilling  to  allow  deviations  from  the  standards. 

Moreover,  since  building  a  ship  requires  precision  sequencing  that  allows  for  just-in-time 
production  of  major  sections  of  the  ship,  these  changes  had  to  be  incorporated  after 
assembly  and  delivery  of  these  elements — significantly  adding  difficulty  to  the 
requirement  changes.  When  coupled  with  the  program’s  concurrent  design  and  build 
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strategy,  this  fact  alone  severely  limited  the  ability  for  either  firm  to  accurately  predict 
cost  and  schedule  impacts. 

The  ambitious  schedule  and  technical  requirements  for  the  program,  in  conjunction  with 
real-time  mission  pressures,  combined  to  place  an  extraordinary  amount  of  strain  upon 
both  the  program  office  and  the  contractors,  ultimately  undermining  their  effectiveness. 
The  LCS  program  did  attempt  to  use  a  spiral  development  approach.  However, 
unrealistic  assumptions,  coupled  with  little  flexibility  in  the  Navy’s  requirements  for  the 
initial  spiral,  diluted  the  benefits. 
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E.  Commercial  Development  of  the  INTELSA  T  Satellite 

The  International  Teleeommunications  Satellite  Organization  (INTELSAT)  has,  sinee  its 
ineeption  in  1964,  pursued  development  of  its  satellite  vehieles  by  utilizing  teehniques 
akin  to  evolutionary  aequisition  and  spiral  development — ^before  those  strategies  were 
fully  developed.  Although  differenees  in  these  development  proeesses  exist,  they  also 
share  many  similarities.  The  INTELSAT  example  shows  how  spiral  development  ean 
even  be  implemented  suceessfully  by  an  international  government  organization,  with  a 
market  monopoly,  to  keep  development  eosts  low  and  aequisition  sehedules  on  time. 

The  International  Telecommunieations  Satellite  Organization  (INTELSAT)  has  been  the 
world’s  largest  eommereial  satellite  communieations  serviees  provider  sinee  its  ereation. 
Formed  as  an  international  government  organization  to  help  facilitate  satellite 
communications  for  the  benefit  of  all  nations,  the  entity  was  given  an  effective  monopoly 
on  the  commercial  satellite  market  due  to  the  high  cost  of  entry.  Over  time,  however,  it 
became  feasible,  and  then  even  profitable,  for  commercial  firms  to  enter  the  market  and 
compete  with  INTELSAT.  In  the  late  1980s,  its  historical  role  as  a  “non-profit 
international  consortium,  to  provide  satellite  telecommunications  services  on  a  non- 
discriminatory  basis  to  all  nations  [. . .  was  forced  to]  mov[e]  rapidly  toward  its  new  role 
as  a  corporate  telecommunications  business  competing  for  customers  in  a  deregulated 
industry”  (7-3297)(Nichols  2001).  In  2001,  the  company  transferred  its  assets  to  a 
private  company  in  accordance  with  a  congressional  mandate  that  fully  deregulated  the 
communications  satellite  industry. 

INTELSAT  satellite  development  provides  a  useful  comparison  with  the  DoD  acquisition 
process  for  two  reasons.  First,  while  INTELSAT  was  very  successful  at  developing 
satellites  quickly  and  efficiently,  the  DoD’s  record  is  more  ominous.  Cost  overruns, 
technical  delays  and  cancellations  were  common  for  the  DoD  in  this  high-risk  area. 

The  key  difference  in  outcome  can  be  directly  attributed  to  the  knowledge-based 
approach  that  INTELSAT  used.  The  second  useful  comparison  lies  in  the  oversight 
process.  Both  INTELSAT  and  the  DoD  have  extensive  external  supervision.  For 
INTELSAT,  the  “cumbersome  nature  of  the  intergovernmental  decision-making  process” 
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(5)(Hecker  2005)  restricted  its  ability  to  respond  rapidly  to  changes  in  the  market.  For 
the  DoD,  the  large  bureaucracy,  along  with  the  need  for  congressional  approval  of 
budgetary  changes,  greatly  restricts  responsiveness. 

Even  though  it  was  originally  a  monopolist,  INTELSAT  followed  an  evolutionary 
acquisition  approach  to  acquiring  new  satellites.  Their  strategy  emphasized  short 
development  cycles  and  keeping  costs  low.  During  these  years,  it  was  noted  as  a 
“dynamic  force  [...  whose]  traffic  growth  and  new  service  offerings  have  required  six 
generations  of  new  satellite  designs  [in  the  21  years  between  1965  and  1986],  each 
offering  ever-increasing  capacity  and  introducing  new  technologies”  (1461)(Bennett 
1984).  During  this  time  period,  total  bandwidth  increased  60  fold — from  50  MHz  to 
3,030  MHz;  and  the  telephone  channel  capacity  grew  just  over  561% — from  480  to 
270,000  channels  (l)(Jefferis  1989).  INTELSAT,  as  do  virtually  all  commercial  satellite 
firms,  continues  to  rely  on  short  development  cycles  to  respond  to  changing  technology 
quickly,  while  keeping  costs  low.  The  newest  satellite  ordered  by  INTELSAT  was 
announced  in  January  2007  and  will  be  launched  in  2009  (de  Selding  2007). 

The  rapid  development  and  deployment  of  commercial  satellites  was,  and  remains,  in 
sharp  contrast  to  the  developmental  path  of  many  military  programs.  Military  satellite 
development,  in  which  “performance  has  been  the  overriding  design  criterion  [. . . 
experiences]  development  times  [of  on  average]  15  years”  (1039)(Parker  2002).  Military 
satellite  programs  rarely  delivery  projects  on  time  or  budget  because  such  programs  place 
a  premium  on  quality  that  is  promised  by  insufficiently  matured  technology.  This  trend 
continues  today  with  the  Transformational  Communications  Satellite  (TSAT),  designed 
to  enable  the  doctrine  of  joint  and  network-centric  warfare.  Upon  program  initiation  in 
2004,  “The  DoD  estimated  [. . .]  that  it  would  launch  the  first  satellite  in  April  2011. 
TSAT’s  current  [...]  initial  launch  date  has  slipped  to  September  2014”  (2)(GAO  2006c). 
Not  only  was  the  initial  development  period  for  the  military  satellite  twice  that  of  its 
commercial  counterpart,  but  the  commercial  satellite  development  time  is  equal  to  the 
delayed  period  of  the  military  satellite  program.  Moreover,  it  is  likely  that  there  will  be 
further  delays  to  the  TSAT  program  as  it  moves  forward.  As  long  as  the  DoD  continues 
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to  design  around  specific  requirements  or  immature  technologies,  it  will  continue  to  face 
significant  cost  growth  and  scheduling  issues. 

When  INTELSAT  submitted  a  request  for  a  development  proposal,  it  did  not  stipulate  all 
end  capabilities,  let  alone  requirements.  Their  request  would  include  basic  desired 
performance  parameters,  along  with  optional  features  that  may  be  technically  feasible  at 
that  point  in  time.  Responding  firms  had  to  provide  an  analysis  of  their  “Must  Bid” 
options,  while  they  were  able  to  respond  to  the  “May  Bid”  options  at  their  own 
discretion.  INTELSAT  considered  the  “Must  Bid”  options  as  “likely  to  be  included  at 
some  stage  during  the  lifetime  of  the  project  and  by  requesting  detailed  technical 
proposals,  individually  costed,  the  Board  of  Governs  would  be  able  to  judge  if  and  when 
they  should  be  exercised”  (l)(Silk  1989b).  Even  options  deemed  “Must  Bid”  would  not 
necessarily  be  implemented  on  the  final  spacecraft.  Eurther,  “so  as  to  maximize  the 
benefit  to  INTELSAT,  bidders  were  also  requested  to  suggest  alternative  proposals  that 
they  considered  would  be  attractive  to  INTELSAT”  (3)(Silk  1989a).  In  this  way, 
INTELSAT  actively  requested  the  developer’s  input  on  a  project  and  the  possibility  of 
applying  new  technology  of  which  it  was  not  aware. 

The  INTELSAT  satellite  development  process  stipulated  the  need  for  adaptability.  In 
this  way,  satellites  could  add  new  capabilities  after  becoming  initially  available,  once  the 
necessary  technology  became  mature.  One  such  example  is  the  INTELSAT  VI, 
developed  in  the  mid-1980s.  This  satellite  “incorporated  significant  growth  potential  into 
its  initial  design.  The  inclusion  of  such  growth  capability  in  an  initial  design  is  unique  as 
launch  economics  normally  dictate  finely  tuned  satellite  designs,  which  maximize 
satellite  capacity  for  a  given  launch  weight  constraint”  (1468)(Bennett  1984).  Although 
there  is  concern  that  the  initial  flights  may  not  capture  all  of  the  value  possible,  “this 
growth  potential  gives  INTELSAT  the  flexibility  to  easily  use  added  launcher  capabilities 
to  introduce  new  and  innovative  services  in  order  to  meet  the  challenges  of  the  future” 
(1468)(Bennett  1984). 

Throughout  all  INTELSAT  satellite  development  projects,  there  remained  only  one  firm 
requirement:  short  development  time.  Most  programs,  such  as  the  INTELSAT  VIII,  were 


47 


“procured  on  an  aggressive  three-year  delivery  schedule”  (81)(Rush  1993).  The  limited 
development  periods  foreed  the  development  team  to  only  use  technologies  that  were 
proven  effeetive  and  could  be  implemented  quickly. 

INTELSAT  development  tended  to  use  mature  teehnologies  that  were  already  space- 
proven.  When  the  INTELSAT  VII  was  developed  in  the  late  1980s,  most  of  its 
components  were  already  commercially  available.  For  the  spaeecraft  bus,  INTELSAT 
used  the  FS-I300,  which  “combines  mature,  flight-proven  subsystems  with  a  large 
structure  and  scaled-up  power  subsystem  to  create  an  economical,  high  capacity  bus. . . 
that  address  the  INTELSAT  VII  requirements  in  a  cost-effective  manner”  (3)(Templeton 
1989).  Many  of  the  individual  components  were  augmented  in  the  same  way.  The 
satellite’s  Attitude  and  Orbit  Control  was  commended:  “all  of  the  hardware  is  flight 
proven  and  off-the-shelf  with  extensive  in-orbit  experience”  (9)(Templeton  1989),  and 
this  principle  was  generally  applicable.  Just  as  importantly,  the  program  did  not  allow 
development  of  risky  technologies  to  proceed.  For  example,  the  “Ion  Thruster^  May  Bid” 
option  [on  the  INTELSAT  VII]  was  not  ineluded  [in  the  final  design]  since  the 
teehnology  was  considered  not  sufficiently  mature  for  inelusion  on  a  large  operational 
satellite”  (3)(Silk  1989b). 

Lessons  Learned: 

The  experience  of  Intelsat  proves  that  an  institution  that  follows  evolutionary  aequisition 
and  spiral  development  can  have  continued  development  suecess.  This  flexible 
aequisition  process  allowed  a  product  to  be  constantly  updated  with  the  latest 
teehnological  innovations.  By  using  only  space-proven,  mature  technologies  in  step  with 
a  knowledge-based  aequisition  method,  cost  and  risk  were  kept  to  a  minimum.  Finally, 
the  history  of  INTELSAT  shows  that  while  extensive  external  supervision  is 
cumbersome,  an  entity  can  still  pursue  an  effective  acquisition  process  with  a  proper 
internal  organization. 


^  An  ion  thruster  is  a  form  of  spacecraft  propulsion  that  creates  thrust  by  accelerating  ions  (a  charged  atom 
or  molecule). 
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IV.  Finding  and  Recommendations 


The  DoD  has  historically  pursued  acquisition  development  using  the  linear  “waterfall” 
method.  In  the  DoD’s  experience,  however,  weapon  programs  frequently  had  a  tendency 
to  experience  increases  in  costs,  reductions  in  capabilities  and  delays  in  schedule  with 
this  method.  In  2000,  the  DoD  officially  adopted  a  new  acquisition  strategy. 

Evolutionary  Acquisition,  to  provide  more  flexibility  in  development  and  avoid  past 
problems.  The  DoD’s  preferred  process  to  implement  Evolutionary  Acquisition  is  Spiral 
Development. 

In  spiral  development,  a  weapon’s  desired  capability  is  known  at  program’s  initiation,  but 
the  system’s  requirements  are  refined  over-time,  with  each  successive  spiral,  based  on 
feedback  from  the  users  and  tests.  Requirements  for  future  increments  depend  upon 
technology  maturation  and  user  feedback  from  the  initial  increments.  Overall,  spiral 
development  is  a  knowledge-based  acquisition  process  that  facilitates  effective  risk 
management. 

Implementation  of  spiral  development  presents  several  formidable  challenges  to  the  DoD; 
when  it’s  applied  to  weapon  system  acquisition,  spiral  development  changes  everything 
throughout  the  acquisition  process.  We  believe  the  challenges  listed  below  arise  from 
both  internal  and  external  sources,  and  must  be  overcome  to  successfully  implement 
spiral  development  within  DoD  programs. 

Challenges  to  Implementation 

DoD  Acquisition  Community’s  Culture  is  Resistant  to  Change 

The  DoD  acquisition  community’s  culture  has  developed  over  the  last  60  years;  how  that 
community  collectively  perceives  goals,  objectives,  requirements  and  risk  will  not  change 
overnight.  Eurthermore,  we  believe  there  is  still  a  widespread  lack  of  understanding 
regarding  the  purpose,  and  even  definition  of  spiral  development,  which  further  hinders 
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its  implementation.  Therefore,  simply  identifying  spiral  development  as  the  DoD’s 
preferred  proeess  does  not  guarantee  that  a  program  will  employ  that  strategy  or,  if  it 
does,  that  it  will  be  successfully  implemented. 

For  spiral  development  to  achieve  its  full  potential,  the  acquisition  workforce  must  fully 
internalize  and  embrace  it.  This  will  require  a  cultural  change  for  senior  leaders,  as  well 
as  other  program  personnel.  Leaders  must  consistently  emphasize  the  process  and 
highlight  successful  exemplars,  so  that  the  institution  as  a  whole  does  not  back-slide  into 
old  habits.  Unfortunately,  for  the  DoD,  with  its  history  and  large,  complex  hierarchical 
organization,  even  when  “the  acquisition  organization  manifests  a  need  to  change  form 
[. . .]  its  very  form  inhibits  such  change”  (Nissen  2006). 

Budgetary  and  Appropriation  Processes  are  Not  Structured  to  Support 
Spiral  Development 

To  plan,  execute,  and  fund  its  weapon  system  acquisition  programs,  the  DoD  relies 
primarily  on  three  principal  decision-making  systems:  the  Joint  Capabilities  Integration 
and  Development  System  (JCIDS),  the  Defense  Acquisition  System  (DAS),  and  the 
Planning,  Programming,  Budgeting,  and  Execution  (PPBE).  Whereas  specific  events 
(these  include  validating  requirements,  receiving  approval  to  start  development  or 
production)  drive  the  JCIDS  and  DAS  processes,  the  PPBE  process  is  calendar-based. 
Eurthermore,  the  budgeting  process  can  take  close  to  2  years  to  get  from  beginning  of  the 
budget  planning  cycle  to  budget  execution. 

Spiral  development,  comparatively,  is  an  innovative  process,  and  its  full  benefits  can  only 
be  realized  when  requirements  can  be  shifted  between  spirals  in  order  to  always 
maximize  the  “bang-for-the-buck.”  Eor  this  strategy  to  achieve  its  full  potential  benefits, 
the  budgetary  and  appropriations  process  must  provide  this  flexibility,  while  ensuring  the 
programs  remain  manageable  and  transparent  from  a  regulatory  perspective.  However, 
Congress  has  not  been  inclined  to  fund  this  new  type  of  acquisition  model,  which  does 
not  have  firm  end-requirements  and  may  evoke  a  perceived  loss  of  oversight.  None-the- 
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less,  spiral  development  ean  provide,  through  appropriate  deeision  points,  adequate 
oversight  while  enabling  DoD  aequisition  to  be  more  flexible  and  effieient. 

The  DoD  must  also  change  its  internal  practices.  Currently,  the  Services  have  a 
propensity  to  fund  and  budget  development  projects  based  on  how  much  they  value  the 
theoretical  end  product.  This  rewards  system,  however,  does  not  always  take  into 
account  the  technical  risks  and  costs  associated  with  development.  When  programs  begin 
to  face  technical  difficulties,  schedule  slips,  and  cost  overruns  (as  they  often  do),  the  DoD 
shifts  resources  from  other  projects  to  cover  the  shortfalls.  As  a  result,  the  Department 
ends  up  partially  and  inefficiently  funding  many  projects,  instead  of  efficiently  funding  a 
few  projects. 

Regulatory  Environment  Impedes  Spiral  Development 

The  current  regulatory  system  (DoD  regulatory  measures,  along  with  the  Federal 
Acquisition  Regulations)  is  “simply  not  designed  to  deal  with  a  program  that  changes 
constantly  and  swiftly.  The  result  is  that  corporate  decision-makers  require  that  the 
program  seek  approval  for  each  spiral,  each  time  that  it  significantly  changes,  which 
means  lots  of  briefings,  reviews,  and  coordination”  (Pingel  2003). 

Under  the  traditional  development  process,  extensive  reviews  are  undertaken — as  the 
project  must  meet  program  milestones.  Full  reviews,  especially  in  preparation  for  the 
Milestone  C  production  decision,  could  take  a  year  or  more  of  testing.  For  spiral 
development,  however,  the  time  from  development  to  production  is  much  shorter. 
Frequently,  spirals  may  not  end  in  operational  spin-outs  that  significantly  alter  the 
specifications  of  the  weapon.  As  a  result,  little  utility  is  derived  from  comprehensive 
retesting.  As  such  assessments  are  pursued,  the  cost  and  time  to  development  are 
significantly  increased  without  a  comparable  advance  in  the  understanding  of  the 
weapon’s  quality.  These  reviews  also  delay  the  fielding  of  spin-outs,  decreasing  the 
effectiveness  of  the  spiral  development  process. 
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Programs  Still  Find  it  Hard  to  Control  “Requirements  Creep” 

In  order  to  capture  the  benefits  of  reduced  development  time  and  costs  from  spiral 
development,  project  managers  must  ensure  that  “requirements  creep”  does  not  occur. 

The  flexibility  of  this  process  allows  a  project  to  rapidly  adapt  to  new  threats;  “however, 
this  benefit  must  be  kept  in  check  to  ensure  there  is  not  a  requirements  potluck”  (Henning 
2005).  While  each  program  has  a  defined  end-capability,  each  spiral  has  a  defined  goal 
and  objective.  Only  under  extreme  circumstances  should  the  program  be  allowed  to 
evolve  away  from  its  original  end-capability,  or  a  spiral  from  its  end  goal. 

Continuous  assessments  should  be  done  to  ensure  that  the  project  is  on  track  to  fulfill  its 
defined  goal.  If  requirements  discipline  is  not  maintained,  then  development  time  and 
costs  will  begin  to  “spiral”  out  of  control  as  projects  try  to  become  all-encompassing,  all- 
capable  systems.  Adding  a  new  requirements,  especially  those  supporting  capabilities 
not  originally  envisioned  for  the  project,  will  cause  costly  development  revisions  that 
undermine  the  effectiveness  of  the  process.  Although  spiral  development  is  flexible,  it  is 
not  infinitely  so.  A  careful  assessment  must  be  made  before  new  requirements  are  added 
to  a  spiral  development  project  and  must  be  determined  with  the  overall  goal  of  the 
project  in  mind. 

Projects  Continue  to  Start  without  Sufficient  Knowledge 

Many  Weapon  systems  programs  do  not  follow  a  knowledge-based  development  process 
that  exclusively  uses  mature  technologies.  The  GAO,  in  its  FY  2008  Assessment  of 
Selected  Weapons,  assessed  the  only  12%  of  the  major  programs  it  reviewed  had  all  of 
their  critical  technologies  mature  at  the  development  start  (which  the  GAO  identifies  as  a 
best  practice)  (GAO  2008). 

Frequently,  overly  optimistic  expectations  for  technological  development  are  still 
proposed  by  contractors  and  endorsed  by  the  acquisition  community.  Feasibility  analyses 
tend  to  be  limited  for  a  number  of  reasons.  A  prominent  example  is  the  need  to  secure 
initial  funding  for  a  program.  The  desire  for  projected  end-state  capabilities  is  tempting. 
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However,  programs  that  proeeed  based  on  immature  teehnologies  are  much  more  likely 
to  experience  significant  cost  growth  and  schedule  slippage,  as  previously  discussed. 

Spiral  Development  Requires  Extensive  Communication  and 
Collaboration  among  Stakeholders 

Communication  between  the  many  stakeholders  involved  with  weapon  system 
acquisition  (the  acquisition  community,  the  contractor  and  the  user  community)  still  tends 
to  be  inadequate,  even  when  leaders  are  using  a  linear  process.  For  example,  difficulties 
in  developing  precise  contract  language  still  arise  from  a  lack  of  communication  between 
the  developers  and  the  weapon  system  user.  Developers  still  have  difficulty  defining 
requirements  with  specific  guidance  to  the  contractor  that  are  not  overly  restrictive  or  that 
stifle  innovation.  User  feedback  is  limited,  and  often  comes  too  late  in  the  process  to 
make  a  discemable  difference.  These  issues,  if  not  addressed,  will  only  manifest 
themselves  more  with  spiral  development — especially  when  several  spirals  are  operating 
concurrently. 

If  Not  Properly  Managed,  Spiral  Development  Can  Create  Logistics 
Complexity 

A  final  area  of  particular  concern  is  the  collaboration  between  the  development  and 
logistics  community.  Most  of  a  system’s  lifecycle  costs  are  accrued  in  providing  logistics 
support  after  the  weapon  system  is  deployed.  Spiral  development  can  exacerbate  these 
problems  by  purposefully  requiring  the  continuous  fielding  of  several  versions  of  a 
weapon  system.  The  program  logistic  costs  can  increase  significantly  as  the  number  of 
fielded  variants  increases,  especially  if  the  funding  is  not  made  available  to  retrofit  the 
systems  to  a  common  baseline."^  Having  blocks  of  dissimilar  vehicles,  with  different 
designs,  subsystems,  and  components,  can  also  make  contracting  for  long-range  support, 
as  well  as  preparing  mission-ready  spares  packages,  more  difficult  (#1570)  (Drew  2005). 
Although  many  of  these  problems  can  be  mitigated  through  careful  planning  and 


For  systems  fielded  in  large  numbers,  such  as  the  F-16  or  F/A-18,  this  is  already  the  case — ^with  the  many 
block  configurations  these  programs  support. 
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configuration  control,  many  in  the  logistics  community  are  wary  of  the  potential  impaets 
from  a  poorly  exeeuted  spiral  development  program. 

Recommendations 

The  DoD  must  gain  eontrol  of  and  shorten  weapon  system  development  cyele  time  in 
order  to  provide  the  affordability,  agility,  and  responsiveness  that  the  military  will  need 
to  faee  the  ehallenges  of  the  twenty-first  eentury.  By  implementing  a  true  “spiral 
development”  proeess  as  the  norm  for  development,  the  DoD  ean  aehieve  lower  eost, 
lower  risk  and  faster  fielding.  Development  should  be  based  on  proven  mature 
teehnology,  and  realistie  budgets  and  funding.  Moreover,  spiral  development  requires 
better  planning  and  diseipline,  as  well  as  improved  eommunieations  and  eollaboration 
between  the  developer,  user,  eontraetor,  tester,  and  logistieian  in  order  to  aehieve  success. 

We  offer  the  following  speeifie  reeommendations  for  the  DoD  if  it  is  to  better  implement 
spiral  development: 

1.  Use  Mature  Technologies  and  Knowledge-based  Practices 

In  general,  development  programs  that  follow  a  knowledge-based  aequisition  strategy 
using  fully  mature  teehnologies  reduee  development  eosts,  risks,  and  development  eycle 
time.  Specifieally,  the  DoD  has  demonstrated  that  when  it  followed  this  approach  (using 
mature  teehnologies),  it  had  more  sueeessful  outcomes  that  were  similar  to  eommercial 
eompanies  (GAO  2002).  In  order  to  maximize  the  effeetiveness  of  spiral  development, 
all  spirals  must  follow  this  knowledge-based  approaeh.  Eaeh  bloek  should  be  based  on 
proven  teehnology,  with  a  five-year  eycle  goal  from  the  start  of  system  development  to 
aehievement  of  the  initial  operating  eapability;  it  should  foeus  only  on  those  elements 
that  will  field  eapabilities  during  that  bloek’s  period. 

The  DoD  already  has  a  policy  that  mandates  that  new  projects  should  only  begin  when  all 
teehnologies  are  mature.  However,  this  is  often  not  the  ease,  and  numerous  programs  are 
funded  that  do  not  follow  this  guideline.  Designated  Senior  Aequisition  Exeeutives  need 
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to  better  enforee  this  poliey  and  not  approve  programs  until  they  ean  demonstrate  that  all 
eritieal  teehnologies  are  fully  mature  (i.e.,  at  least  TRL-6). 

2.  Program  Must  Have  Greater  Requirements  Flexibility 

To  effeetively  implement  spiral  development,  users  must  allow  more  flexibility  with  their 
requirements  so  that  developers  ean  make  the  needed  eost,  performanee,  sehedule  trade¬ 
offs  as  they  arise.  These  revisions  may  ehange  the  outeome  of  a  speeifie  spiral,  but  not 
that  of  the  final  required  eapability.  Current  DoD  programs  do  not  generally  demonstrate 
this  adaptability  until  budget  overruns  require  aetion.  Users  must  also  trust  that  the 
programs  will  eontinue  as  planned,  and  be  willing  to  aeeept  less-eapable  systems  (the 
“80%  solution”)  earlier  that  will  then  evolve  to  desired  eapability  in  later  bloeks. 
However,  eost  must  be  viewed  as  a  design  eonstraint — otherwise,  program  baselines  may 
be  less  well  defined. 

3.  Address  the  Budget  Challenges 

Development  teams  need  to  be  able  to  take  advantage  of  opportunities  as  they  arise  or  to 
avoid  teehnieal  diffieulties  as  neeessary.  As  requirements  shift  between  spirals,  programs 
need  greater  latitude  to  realign  funds  within  the  seope  of  the  total  program,  if  neeessary. 
Effeetive  oversight  ean  be  maintained  through  the  more  thorough  pre-planning  stage, 
along  with  periodie  milestone  reviews. 

When  using  spiral  development,  program  managers  will  find  that  requirements  evolution 
will  make  it  more  diffieult  to  develop  program  eost  estimates;  however,  it  must  be  done. 
Programs  must  eontinue  to  budget  for  R&D  in  future  bloeks,  even  while  the  eurrent  bloek 
is  underway. 

4.  Adapt  Test  and  Evaluation  Processes 

The  DoD’s  testing  and  evaluation  polieies  and  proeedures  were  designed  to  support  the 
legaey  aequisition  proeess  with  its  single-stage  development.  With  spiral  development, 
systems  are  developed,  aequired,  and  deployed  in  stages.  Therefore,  testing  and 
evaluation  polieies  and  proeedures  must  be  evaluated  and  adapted  to  support  spiral 
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development  and  its  multi-staged  approaeh.  The  goal  of  the  testing  and  evaluation 
programs  should  be  to  explore  the  system’s  (and  its  components’)  strengths  and 
weaknesses  to  provide  feedback  to  future  spirals  (Nair  2006).  Early  operational  testing  is 
still  important,  but  the  test  community  must  view  partial  capability  enhancements  of  early 
blocks  as  a  system  success. 

Those  programs  that  make  satisfactory  progress  should  be  fully  supported.  Those 
programs  that  do  not  exhibit  such  progress  should  be  reevaluated  and,  if  appropriate, 
should  be  restructured  or  cancelled. 

5.  Incorporate  Logistical  Concerns  Early  in  the  Development  Process 

Evolutionary  acquisition  and  spiral  development  produce  fielded  weapons  much  faster 
than  under  the  traditional  method.  These  systems  are  also  frequently  updated  with  each 
subsequent  spiral.  Although  this  process  can  provide  the  warfighter  with  more  capability 
sooner,  it  can  create  greater  demands  on  logistics  planning  and  support.  Different  system 
configurations  can  impact  the  provision  of  spares,  training,  and  maintenance. 

Minimizing  these  impacts  requires  the  early  and  consistent  involvement  of  logistics 
planners.  Eogistics  planning  must  be  fully  integrated — from  the  program’s  inception 
through  all  the  spirals;  and  effective  communication  is  vital. 

Although  some  equilibrium  may  have  to  be  reached  between  faster  fielding  and  lifecycle 
logistics  considerations,  we  believe  that  shorter  cycle  times  should  generally  prevail. 

6.  Ensure  that  Programs  are  Properly  Managed 

By  their  nature,  programs  that  use  a  spiral  development  strategy  will  generate  a  higher 
volume  and  intensity  of  program  office  and  contract  activity.  There  may  be  several 
spirals  under  contract  concurrently.  Eurthermore,  the  programs  should  maintain  and,  if 
appropriate,  exercise  the  option  of  competition  (prime  and/or  subsystem)  at  each  block — 
depending  on  performance  and  cost  results  from  prior  blocks.  This  level  of  activity  will 
require  program  offices’  to  potentially  have  larger  staffs  (to  prevent  burnout)  with  a 
different  skill  mix  than  exists  today. 
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7.  Implement  a  Modular  Open  System  Approach 


The  use  of  a  Modular  Open  System  Approach  allows  for  the  more  rapid  insertion  of 
updated  technologies.  This  capability  reduces  the  development  cycle  time  and  facilitates 
the  implementation  of  spiral  development.  Its  use  should  be  broadly  expanded  within 
DoD  weapons  programs. 

Modularity  is  defined  as  a  “special  form  of  design  which  intentionally  creates  a  high 
degree  of  independence  or  ‘loose  coupling’  between  component  designs,  by 
standardizing  component  interface  specifications”  (Sanchez  1996).  Modularity  facilitates 
less  complicated  and  more  expeditious  integration  of  new  components  into  previously 
fielded  systems.  Modularity  also  increases  the  incentives  for  developing  and  fielding 
modifications  to  current  assets  by  reducing  the  transaction  costs  associated  with  their 
implementation.  If  modularity  is  implemented  correctly,  new  components  should  be 
more  interchangeable  with  old  components.  One  of  the  primary  benefits  is  the  improved 
capability  to  make  rapid  improvements. 

Although  physical  compatibility  should  be  a  goal,  modularity  is  particularly  important  for 
software  and  software-intensive  systems.  Software  compatibility,  with  published 
interfaces,  helps  to  enable  developers  to  deliver  applications  that  can  be  seamlessly 
implemented  in  a  fielded  system. 

8.  Ensure  Programs  use  Concurrent  development 

Concurrent  development  is  an  important  enabler  of  spiral  development,  and  represents  an 
important  distinction  between  evolutionary  acquisition  and  the  traditional  method  of 
acquisition. 

Spiral  development  relies  upon  the  concurrent  development  of  sequential  spirals;  that  is, 
the  development  cycle  of  spiral  N  and  spiral  N+l  will  partially  overlap.  Rather  than  the 
spirals  having  a  dependent  relationship  (spiral  N+l  is  initiated  at  the  successful 
completion  of  spiral  N),  they  have  an  interdependent  one;  they  are  coupled.  Spiral  N+l 
is  initiated  before  the  previous  spiral  is  completed,  but  it  is  dependent  on  information  and 
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feedback  from  that  development.  Consequently,  planning  for  and  initiating  spiral  “N+1” 
is  a  critical  spiral  “N”  task.  This  level  of  concurrency  requires  frequent,  bi-directional 
communications  to  be  effective.  If  communication  is  poor  or  infrequent,  the 
development  team  may  find  that  decisions  made  in  earlier  stages  “impose  constraints  that 
may  hinder  subsequent  stages  and  thus  result  in  irreconcilable  conflicts  (and  thus  waste) 
or  additional  time  and  costs  in  development”  (AitSahlia  1995). 
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V.  Conclusions 


During  the  Cold  War  era,  the  defense  establishment  was  primarily  concerned  with 
weapon  system  performance  and  maintaining  technical  superiority  over  the  Soviet  Union; 
cost  was  a  secondary  objective.  The  post-Cold  War  era  saw  the  focus  shift  to  cost  and  to 
collecting  the  “peace  dividend.”  With  the  terrorist  attacks  of  September  11,2001,  our 
perception  of  national  security  was  altered  again.  The  world  was  still  a  dangerous  place; 
however,  in  this  new  world,  with  irregular  and  asymmetric  warfare,  the  focus  of  DoD 
acquisition  must  be  on  schedule.  Shorter  acquisition  cycles  can  field  better  performing 
weapons  sooner,  at  lower  cost.  Our  troops  and  our  country  deserve  no  less. 


Shorter  Acquisition 
Cycie  Times 


improved  Performance 
and 


Reduced  Cost 
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